-----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 <loki@fosdem.org> http://www.fosdem.org /\\ FOSDEM 2006 :: 25+26 February 2006 in Brussels _\_v Free and Opensource Software Developers European Meeting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDga8hr3NMWliFcXcRAlTrAJ4gUdRWEKBi3zzE7QtlnIv78ZR//gCfUNnZ wCGNo2jsG3ak7XqIVpMyGoA= =9IXf -----END PGP SIGNATURE-----