-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henne Vogelsang wrote:
Hi,
On Sunday, November 20, 2005 at 01:15:58, Pascal Bleser wrote:
Does anyone happen to know (and I hope a few packagers @SUSE are reading this list ;)) if there's some kind of policy for SUSE's supplementary repositories ?
Nothing other than: "it should build" ...
The question is: do you (SUSE devs) always keep up with the latest versions of applications that are in supplementary ? Or is it "when we have the time" ? I can imagine it has low priority..
True. It all depends on how the maintainer finds time....
Ok. Thanks for clarifying.
As already discussed very briefly on IRC with Stephan Binner, this leads us again to what Robert
(AFAICR) pointed out in one of his mails: the SUSE staff using different tools than the community
packagers.
Mostly because the spec files made by SUSE developers only work on one single SUSE Linux release,
where as almost all community packagers maintain their RPMs for several SUSE versions. I guess most
of use work "single source" (i.e. one spec file / src.rpm for all SUSE releases).
Because of "neededforbuild" including packages that are absolutely not related to building the
package or not (e.g. selinux), one cannot use a src.rpm of SUSE Linux 10.0 and build it on, say, 9.2
or 9.3.
I don't see the point of "neededforbuild" anyway. Stephan told me it was because symbolic names like
"kde-devel-environment" (or something like that), but those should be virtual provides in the first
place (or an empty package that just "Requires:" (kdelibs3-devel, qt3-devel, etc...) and "Provides:
kde-devel-environment"). I mean, other distributions are able to handle it without relying on
special tools (besides chroot management).
I have to say that personally, I don't like the idea of having to use specific tools (except
rpmbuild) to be able to build spec files, instead of just using rpmbuild. Wrapper scripts are nice
because they can help with managing the chroots, automagically installing required dependencies in
those chroots (like y2pmbuild is doing), but one mustn't rely on
- - a specific toolchain that does some black magic with spec files
- - specific rpmmacros settings that are not standard (some distributions are doing that, but it
should be avoided if possible)
While such tools or environments can provide extra value (e.g. the chroot management of y2pmbuild),
they should do a plain rpmbuild in the end, because you get a different behaviour if you just use
rpmbuild or, say, y2pmbuild.
But maybe that's just my opinion ;)
And, yes, I know this is supposed to be solved by the build servers in some 4 months from now, at
least the fact that SUSE devs and community packagers use different toolsets.
cheers
- --
-o) Pascal Bleser