On Tue, Sep 06, 2005 at 04:07:51PM +0200, Pascal Bleser wrote: > > Imagine a large pool of packages, not a distribution, and not even > > called testing. Just a kind of primordial soup of packages. Everyone can > > submit packages there. > > Are you thinking of a central hosting for those packages ? > Or just information about where a package is available ?
Central hosting, automated rebuilds when packages earlier in the dependency chain change. > > Now imagine you could define a larger entity, let's call it a package > > set, which you can create and be responsible for, and where you could > > collect packages that have passed your review and meet your quality > > standards. You could call it "Pascal's approved SUSE addon packages", or > > form a group of people to help you who also have the respective > > privileges for that package set. Hey, you could even create three of > > them and call them stable, unstable and testing ;-) > > And where in that idea are the package maintainers ? > Personally, I don't believe in such a model if there aren't dedicated people > that maintain every > single package. Having dead, unmaintained RPMs /is/ an issue. Of course every package has a maintainer - the person who submitted it to the system for the first time. Unmaintained packages need to be taken care of in any approach - maintainers disappear or lose interest for any reason. > Sonja, this is a totally different approach you're proposing there, and I > really don't know how > viable that would be. That's why we're discussing, isn't it ;-) > - - who's in charge of a package => keep an eye on new releases, keep an eye > on security fixes, > contact person for feedback The package maintainer. If they are not reacting, or not providing security updates, the package needs to be marked as unmaintained, or maybe even removed. That's a policy decision (and also a question that is present in any approach). > - - how would that work with package installation front-ends like YaST2, apt, > yum, if the RPM files > are not hosted where the "package set" is defined ? What would the requirements be? A package set would, for example, result in its own install source you can configure YaST to use. Different package sets would depend on others. To reuse the example, the openSUSE community approved reviewed addon set might be based on SUSE Linux core as the base distribution, but in addition contain packages which are - not in the core distribution - newer than in the core distribution - better than in core (i.e. feature-adding patches which didn't or will never make it into core SUSE Linux) We need to take care about dependencies both during build and in the installer. In the second and third group packages will override those in the core, so both the build server and YaST (or any other installer people will want to use) need to be able to handle a "layering" of package sets and the resulting install sources. Which we'll still have to implement, but fortunately we have both the build system and YaST under our control. So conflicting and duplicate packages are not necessarily a problem - it can also be a feature to have variants packages which contain, for example, experimental features, or are just newer. (Add requirement: show per-package information on the web frontend which variants exist for a package, in which package sets they are, what their dependencies and purpose are. Possibly also make this information available in YaST, though it might add more confusion than real advantages. In any case make YaST deal with multiple installation sources in a defined order of preference.) 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]
