Hi *,
Post by Luis VillaPost by Christian Lohmaier[...]
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.
Post by Luis VillaPost by Christian LohmaierIt 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?
Post by Luis VillaAnd 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.
Post by Luis VillaPost by Christian Lohmaier- 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?
Post by Luis Villaor 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.
Post by Luis VillaPost by Christian LohmaierPost by Luis Villamulti-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?
Post by Luis VillaThis 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.
Post by Luis VillaPost by Christian LohmaierGTK.
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.
Post by Luis VillaTo fix this problem, you must recompile
not just gnome, but every package that depends on GNOME.
No. Thats not true.
Post by Luis VillaWe 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".
Post by Luis VillaPost by Christian LohmaierFurthermore: 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