On Tue, Sep 06, 2005 at 05:34:47PM +0200, Pascal Bleser wrote: > Maybe a more distributed approach would be worth investigating as well. > I particularely like Debian's idea of its unattended build daemon, even > if it's worth improving. But like that, even people who don't have the > necessary know-how to write RPMs but who would like to actively contribute > can offer their hardware ressources as "build servers".
Yes. Especially if we can find organizations who'd like to donate build power on other platforms than ix86 and amd64. This opens up another can of worms, though: how can we trust a package which we didn't even build ourselves? Anything can happen on a remote build host, and reviewed spec files and patches won't help us a bit. How does Debian deal with that? > Now, what was so wrong with what I wrote in my previous mails ? ;) [...] > How is that so different from the current situation ? (besides enhancing > YaST2 to use such "package > sets" (= installation sources) with more ease) Remember where the discussion started: giving up the idea of centralized control, and of having only stable/unstable/testing as repositories. Package sets are mini repositories where we can loosen much of the control and allow more experimental stuff to happen, without losing the possibilitiy to have a tight review process on _some_ of them. Don't even think that we'll allow random submissions into the core code base that will also be used for the $$$ products. > Err.. well.. they /are/ a problem, unfortunately. > And one I cannot see us solve by any means, unless we eventually kick the GTK > and GNOME developers > in the butt for not versioning their libraries properly. > > How would you solve: > - - gimp 2.2.8 needs gtk2-2.4.0, all in stable, fine > - - xchat needs gtk2-2.4.0 as well, all in stable, fine > - - upgrade to gimp 2.3.0, that needs gtk2-2.8.0, provided in an unstable > package set > > Upgrading gtk2 from 2.4.0 to 2.8.0 will break xchat, for sure (been there, > seen that already). I'm not familiar with GNOME internals, so forgive me if I get the dependencies wrong, but one way could be: - Packager A maintains a package set "bleeding edge GNOME" which, amongst others, contains the newer gtk2, and overrides the GNOME packages in SUSE Linux core. All other packages needed for a complete system are taken from SUSE Linux core. - Packager B provides the newer gimp and marks it as dependent on the package set "bleeding edge GNOME" because it needs the newer libraries. - Packager C notices that xchat doesn't work with the newer gtk2 and rebuilds it against "bleeding edge GNOME", provided that it still builds. If not, she provides a patch. In any case, this is now a variant of the xchat package. Sonja -- Sonja Krause-Harder ([EMAIL PROTECTED]) Research & Development SUSE Linux Products GmbH --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
