Re: Sorting out the prerequisites: Package names

[Christian Lohmaier <cloph cup uni-muenchen de>]

Hi *,

On Sat, Aug 27, 2005 at 04:10:47PM -0400, Luis Villa wrote:
> On 8/27/05, Christian Lohmaier <cloph cup uni-muenchen de> wrote:
> > On Sun, Aug 21, 2005 at 04:56:48PM -0400, Luis Villa wrote:
> > > On 8/15/05, Christian Lohmaier <cloph cup uni-muenchen de> wrote:
> > [...]
> > Why do you imply that a cross distro specfile is automatically a bad
> > one? Why do you think debian manages to provide the same debs for a
> > variety of debian-"distros"?
> 
> Because all of those debian distros are derived from the same core, so
> that when one package depends on libfoo, they all know the package is
> named libfoo, not libfoo2, nor libfoo-2, nor foo-2, all of which can
> and are the case when speaking of a more varied (i.e.,
> non-debian-derived) ecosystem of distros.

Exactly. Thats why I want consistent naming for gnome-packages. 

> > It is becasue they have guidelines, things other packages can rely on.
> > 
> > Given that gnome (exclude gstreamer here) is rather self-contained (only
> > very few external dependancies and on top of that these are very common)
> 
> That's not actually particularly true.

So what external stuff can you name that gnome relies on, is not part of
gnome-releases and is not likely to be present on any current distro?

> And at any rate, it isn't as
> important as the applications that install on top- for example, all
> the major distros now ship tools built on top of gtk and/or pygtk, and
> many of them name those libraries differently. So if you pick 'one'
> name for gtk, and attempt to use that name across all the major
> distros, you'll end up uninstalling important parts of each distro,
> because you picked one name for gtk without fixing all the
> dependencies up the stack.

Why would you uninstall other stuff? If you replace gtk with a newer
version of GTK, why should the gtk-dependant stuff no longer work?

I think you really missed the meta-package stuff I meantioned as well.

Furthermore I don't speak about providing the very same binary packages,
but bilding those from the very same sources/with the same specfile.

You can customize the distro's preferred install-locations with a
suitable ~/.rpmmacros file. This is enough customization it needs to
adapt to a specific distro IMHO.

> > - why shouldn't it be possible to do a good set of rpms that work
> > equally well on every distro out there?
> 
> A very long list. I've gone into it in some depth on this list before,
> so check the archives,

Any timeframe you can give?

> or  just take my word for it. Ximian spent a
> couple man-decades packaging things for different platforms, and did
> not do that for fun. They did it because the alternative (one package
> set everywhere) just didn't work.

Just ask yourself why this system doesn't exist anymore. Ask yourself
whether it is worth so spend the same effort in packing it for different
systems and then realizing that it is an unmaintainable monster.

> > > multi-distro naming is a problem we need to solve, while per-distro
> > > naming is not, unfortunately, a problem we actually have. So we should
> > > probably, uh, go ahead and solve it :)
> > 
> > Say what? You don't have a per-distro naming problem? (Or was it
> > supposed to read "now"?
> 
> I mean no one is giving us a way to build packages on each distro.

What do you mean with that?

> This team is only being offered, tools-wise, an easy way to build
> multi-distro packages, so even though that is vastly suboptimal, that
> is what we have to deal with.

Sorry, but this really confuses me. First you write you want seperate
packages for each distro because you think this is the only way to
provide "working" packages.
But now you write that we can only provide multi-distro packages (one
binary to be installed on different distributions).

Even though my effort for a unified naming of the packages is not
necessarily directed to multi-distro binaries, it surely is nothing that
should avoid multi-distro packages. It would make this task much easier.

When you say multi-distro packages, then you actually support my request
to clear out the package-naming problem. You cannot have multiple
distro-specific package names in one multi-distro package.

> > Just take this small example:
> > GTK.
> > Distro1 names their package GTK+2
> > Distro2 names their package GTK2+
> > Distro3 names their package libgtk2
> 
> > So to support these three distros without clearing out the
> > package-naming problem, *every package* would have to contain three
> > different "Requires:" lines along with a complex method of checking the
> > various distros during building.
> > 
> > While this may be solvable for one or two packages, this gets worse when
> > having a look at the library-stuff. There naming schemes differ even
> > more.
> 
> I think you prove my point.

No. My point is that it is not possible to maintain a set of specfiles
that are distro-specific. Your point "making working packages for
specific distros" cannot be achieved since you would have to focus on
one distro alone, maybe two. But you cannot keep up with maintaining the
specfiles for two distros.

Just try to make packages for Fedora and Mandrake from the very same
specfile. According to your goal "works well", you would have to follow
the individual distro's packaging guidelines. The difference is so big
that it is not doable.

> To fix this problem, you must recompile
> not just gnome, but every package that depends on GNOME.

No. Thats not true.

> We can decide
> here that the answer is to call gtk 'GTK+2', but then we not only have
> to build GNOME for distro 1 and distro 3, we have to build their admin
> tools, and whatever else they ship that depends on gtk. Or we can just
> tell people to install our one-size-breaks-all binaries, I guess. :)

No. You simply provide a dispro-specific meta package that requires
"unique name" and provides "distro-specific name".

> > Furthermore: I thought the goal of the GPP was not to provide binary
> > packages, but to allow curious users to download the tarballs and build
> > RPMs from these tarballs without further modification.
> 
> The original goal of this team was to provide rpms and .debs. I don't
> see any reason why this shouldn't remain the goal.

No packages were provided the last years, rpms are not buildable from
sourcetarballs, many packages don't even contain spec-files.

Sure. When the goal is to fly to mars, don't even bother with trying to
go to the moon first.

Replace "goal" with "shorttime goal". Now better?

ciao
Christian
-- 
NP: Metallica - Jump In The Fire