Packager

From openSUSE

Packager Brainstorming

The following are ideas from the opensuse mailinglist. They are unsorted and incoherent, since they come from various people. Once we have enough items on here we can start making them more coherent. Via the mailinglist.

This list can be used by SUSE.de to integrate into their own discussion. Here is your chance to contribute to exactly how we are going to make openSUSE work "openly" and how to innovate and not just do what others do. Integrate all the good things others do and do more than that. Look into the future. Be inventive. Think outside the box or just report your own experiences.

General ideas

• We need a simple mechanism that will use potential from the whole world. Otherwise, if we go directly for a perfect solution, we may never launch it. Here are the objectives I see and how to accomplish them:
  • Learn from positive and negative things from Debian(Ubuntu)/Fedora/Gentoo and others.
  • We need a low traffic packagers mailing list.
    • Is a low traffic packager list not a contradition in terms? ;)
    • Not necessarely, as there currently only are very few packagers for SUSE
  • Are we looking at a different kind of package other than RPM or DEB here? Rathen than a *Red Hat* Package Manager file - is there any necessity/scope for an openSUSE Package Manager file - OPM?
    • the package management is one of the most important subsystems of an operating system, and relying on proven, well-known package formats and packaging tools on the backend is crucial - I don't think we shoud reinvent the wheel as far as RPM is concerned; we must take the discussion to the many options we have for front-ends to RPM
  • Central hosting, automated rebuilds when packages earlier in the dependency chain change.
    • This is *really* complex to set up, there are a lot of things to think about, policies to define, rules to be followed, technical infrastructure to be set up. It's great to have the momentum, the will to make something happen, but it will need some time and long discussions to properly set that up. So don't get rushed into something not feasible or which is already broken by design. There are a number of people who are really experienced with all of this (yes, I humbly include myself ;)) and, believe me, it's much more complex than what most of you think.
    • Since when has a lot of work and complexity stopped human inventivity? Only by trying something new can we actually have new ouststanding results. By limiting ourselves to the current and old we are limiting our success to the old. This is a brain storm and not a brain lame ;)
  • Let's think further than the Debian model, please.
• Some info on building packages:
  • SUSE_Build_Tutorial and **Novell Guidelines
  • GURULABS-RPM-GUIDE-v1.0.PDF

Buildservers

• Our Roadmap talks about build servers. The issue is how to allow packages from various sources to be integrated and how to integrate them into a future community driven packaging system. The Roadmap explains that openSUSE plans to bring packagers together. How are we de facto going to do this and enhance the usability and create the distro we are all dreaming about.

• A public build server will resolve many unknowns. Imagine the build server only accepts a URL to the source tar ball. That URL is associated with the compiled RPM so that download users may verify the source URL. We'll also maintain a list of domain prefixes that the build server may use to get sources. Then it won't really matter who built the RPM - the source is verified and the build environment is trusted.

• How to protect the host from being flooded. We can have a few people who authorize uploads bigger than a certain size. To distribute the workload among the authorizers, we can create multiple brackets, e.g. 1MB, 10MB, 100MB. We can also maintain a quota per user to avoid flooding through many small files.

• Are going to use SUSE.de autobuild?

• In my opinion one of the first things that actually would be useful is that SUSE starts to be more open what their internal build infrastructure is concerned. Currently in my opinion it is unnecessarily complicated to do some things when building packages because information about SUSEs Autobuild is hidden behind the wall. I am pretty sure the better the build infrastructure is that is in public the more package are actually contributed.

• 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". They "just" need to have a daemon running, that pulls source RPMs from a queue, builds and validates it, and then submits potential issues or even the binary package back to the central repository. Obviously, this concept involves a lot of potential security issues.
  • Can we 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?
  • How is security handled in other peer to peer computing clients like SETI@home. Maybe a SUSEbuild@home system would create a huge compile cluster?

Repositories

• How to collect a large number of RPMs We have to allow everyone to create a free account and to upload RPMs.

• Look for instance at the current repositories that exist. Why is it so hard to use them? Because they are spread around over different "projects" with no common base, with no coordination and with very limited communication. That situation is pretty hard to solve because everyone is used to his own webspace, spec macros, build structure, repostructure and everything else that is neccessary to manage a repository of packages. Dont get me wrong everybody like pascal, james, susers-*, the packmans have right to be proud of what they archived and its a good thing that we stepped forward and made things happen. But now its time to take it to the next level and work together under the hood of openSUSE, which is a process that, by the way, some susers, pascal and we (packman) already started.

• You need a lot of space to host those packages

• Maybe we should integrate yum and apt and yast repositories into an universal yast system?

• How do we integrate packman into this http://packman.links2linux.org. Should packman be the only place? Do we need anything else apart from packman?
  • Will this be possible at all? Packman contains packages which are illegal in a lot of countries. If this project want's to stay under the umbrella of openSUSE such packages are surely out of this game (think of copy-protection circumvention, and unlicensed media codecs). Maybe it would be a good idea to have a single repository for this kind of packages outside of the openSUSE project.

• Wouldn't it be neat if some of these (the main, trusted ones really) were available to select as install sources in YaST after the main install, so that they could then be available for installing more packages, or indeed for updates. The biggest problem people have with third-party packages at the moment is finding out about them.

• Talking about "unsupported", that's where I have my gripe with including "trusted" repositories into YaST's configuration. YaST would need a few refinements for that:
  • downloading a list of repositories from a central location (e.g. download.opensuse.org) to keep up-to-date with new repositories or changes within these, to be able to "refresh" the list of 3rd party repositories, like YOU is doing now for mirrors
  • Have a description field for YaST2 repositories, where we could give information about what to expect in a repository (e.g. multimedia (with a warning about possible infringements depending on the country you live in), experimental gnome packages, etc etc)
  • manage RPM keys in a secure manner, because YaST currently doesn't check package signatures
  • have a "level of trust" or a stable/unstable/experimental label on the repositories, just to let the users know whether they're taking a risk or not
  • With those features, yes, it would be a great benefit for many users if they could just add the 3rd party repositories from YaST. After installation, YaST would be preconfigured with the current sources and you would have an option to add supplemental repositories, but instead of having to find out the information on the internet, it would be fetched/refreshed from a central location and shown as a list where the user could just select which repos to add.

• In principle a totally open upload policy is acceptable and certainly advisable for a seperate repository, for arguments sake, let's call it SUPER repository. SUSE and also the OSS release itself needs to stay stable and commercial grade to be able to be valued as a product in the business and normal user community and by a wider audience, which after all is the basis for the commercial future at Novell and SUSE. An addon reposiory around a community based 1 CD install could be much more experimental than our mainstream can. SUPER = Experimental - SUSE Linux = Stable branches. The name does not need to be that ;)

• Are you serious? People should install random software on their systems? Trust is important here. If the first packages arrive which break user systems, delete their data, install backdoors, etc. openSUSE will suffer from it. I too think everyone should be able to contribute packages, including people who have not yet much practise with rpm (I for example am just learning how to do them), etc. But those packages should be reviewed by more expierinces and trusted people before they land in the repositories.

• But how is quality management handled if everyone can upload random stuff? Is a staging, unstable, untested, or whatever you'll call it repository enough?

• The best option to implement that would be to have different repositories. One for stable, one for unstable and one for testing (or call it "trusted", "untested" and "untrusted"). Like that every user can choose what repositories he wants to see in YaST2. In a way, it actually is a state or "quality label" that's down to every single package.

• If we split into 2 or 3 repositories (stable/unstable/testing), the user can choose what repos he wants to "see" in YaST2. If he's keen to install bleeding-edge packages, he can add the "unstable" and/or "testing" repositories. If he wants to stay on the safe side, he only adds the "stable" repository.

• Of course, this system isn't perfect, and might bring us in the same issues that Debian sometimes has. If someone decides to package the latest-and-greatest development version of some GNOME libraries and someone else builds the latest GIMP devel version that requires those latest GNOME libraries, we're in for a massive library upgrade and that will most likely nuke all the other GNOME applications on the system.

• 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)

• 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. 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 ;-)

• But this would be only one package set of many, and SUSE Linux core would be another, and SUPER maybe yet another, with different levels of control and trust, and us Novell people only controlling very few of them.

• 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.)

• Could package set not be as simple as a spec file witho only version based requires and no real binaries being installed? That way that depencency would require a specific set of packages.

• 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.

• What about having two repositories? One with trusted, checked, well maintained packages, and another where _anybody_ can put in packages, and YaST displaying a BIG RED WARING to the user if he/she selects such an untrusted package for installation?

• First: comming from the Fedora world I am deeply impressed by their system: on the one hand the base system with all the packages which are needed (!) for a normal system, and which is the base for the commercial stuff. And the extras repository for the packagers of the community, with all the other stuff. And there are for both some kind of development branch, too, so we can learn a lot looking at them and adopting what we need.
• Second: The Fedora Core extra server could be a possibility to get a large number of well maintained specs which are all from the same quality. It would be very cool if these two distributions would have compatible specs for the "extra" branches to exchange the specs (and only build the packages automatically new on the SUSE systems) - or, if compatibility is not possible, we should be able to import them easily to spend the work on more important things ;-) --Liquidat 17:58, 27 Oct 2005 (MDT)

A packagers world

• Anyone would be invited to join in. Anyone can apply. But that involves:
  • being the committed maintainer of the package
  • accepting to be reviewed, at least in the beginning
  • follow some guidelines on how to write the packages
  • maybe also being on a central mailing-list with the other packagers

• We will still have a stable SUSE distribution every 8 months, so we won't run into those issues. That stable/unstable/testing would apply to every single "3rd party" package itself.
  • testing = not reviewed, not tested
  • unstable = reviewed, not much tested
  • stable = reviewed, tested by at least x people

• A packager system should be webbased and allow the packager ease of maintenance of new source (should contain information on source location). This would allow the building of sources from trusted orginal sources.

• The quality of the packages: building good RPMs (i.e. writing good spec files) for a distribution means having much experience with it (both building RPMs _and_ knowing the distribution well)

• The problem is identifying quality packages. One solution to this problem is identifying quality over quantity. Another one would be to let the whole of us decide and express our finding of quality in an easy way. I myself find the "quality over quantity" approach not to good. It does not fit into my understanding of "open". And thats what we want to be.openSUSE not somepeopledecidesomenotSUSE..

• Packages should be allowed from any source regardless of the packagers seniority or trust level.

• Signoff can provide with level's of trust in case packages need to be tested.

• IMHO the first goal we should acheive rapidly is a categorisation of the packages and a (?) vote system to know what package must be included among all of the same kind. For example, what cd writer package do we need? what editor? of course it can be a "s" at any one (we can choose more than one).

• What is trusted? The first intrusion point for not trustworthy code is the spec file. You can do all kind of nasty things with RPM trigger scripts because you usually install them as root. So we need a trustsystem for the Packager as well. With the current repos it is the gpg key from the packager. But gpg is a bit hard to understand and handle for the "normal" user who just wants a package.

• How to structure us a way that we allow innovation forks, yet still create a usuable/stable product for those who do not want/know how to fix things, when they break. Opening to public usually does result in product fork weather we like it or not. Some users will think of this "let's get together" type of hippy philosophy to be aggresivly assertive and dogmatic, and will try to present the product in a different light ( better by their standards and design "vorsprung durch technik !!!" ).

• Maybe we should not call it "fork" as the word is too strong. how to keep things open and growing fast with a low entry point to packagers, yet at the same time find ways to control - QA the output for the packages to be usable.

• We could prevent forks from ever happening by allowing a very flexible packager system to accept any sort of deviant package. It is up to the user to actually subscribe to such "deviant" repositories, packages via a softwar warehouse or modified yast.

• How do we create a really democratic and open non elitist distribution-contribution structure, as such a structure will completely destroy any need for a fork, since all ideas people have are actually integrated in some way.

• Bug-tracking system. I think it's important to have a bug-tracking system up for contributed packages. Probably we don't need to discuss the advantages of that.
  • Don't we already have a bugzilla?
  • Yes, but is Novell willing to use this for all the contributer's packages? We will see. For example Ubuntu's bugzilla is only for their supported main packages. Other packages (their universe and multiverse repositories) have a seperate bug-tracking system, they don't allow them in their main bugzilla.

• Someone should also do some investigation to ensure that the packages are free of legal issues (at least as far as a non-lawyer can tell) and known security issues before the packages land on the servers. Packages with known security issues should not be commited at all until a patch is made (or maybe put into some seperate repository with a big red warning)

• We can setup a "new package proposal commission". That is a group that goal is to make a survey on the new apps available elsewhere. _not_ to host them and debug them, but to look at the already done work and see if it may be included (list of dependencies...). If a package seems promising, a member of the commission could be in charge to join the package dev team in the goal of making a SUSE 10.0 rpm. Usualy it's a volunteer who makes suse rpm for not distro included product (was the case, I remember for lyx or audacity at the beginning).

• With red-carpet, you could subscribe to the stable channel, but still install stuff from unstable, and dependencies would be met from the subscribed channels first, and then the unsubscribed on

• File system layout as virtual folders, This just an idea, and more knowledgeable people will probably pull it a part, but here goes:
  • The purpose of a standard file system layout is to organize related items, and do interesting things like backing up of only part of a file tree. However, why should we - as users and packagers - do this filing? Shouldn't the computer be doing this for us? Virtual folders exist in most popular mail clients today. A virtual folder is a saved search for a regular expression which to a user looks like a directory or folder. An email message can thus appear in any folder that matches the search criteria. Why not apply the same principle on the file system itself, using available standards like executable binaries in /bin, /sbin, /usr/local/bin and so on? When a user asks for Kontact today, a number of files in different fixed folders must be accessed, yet in the end they all refer to an inode somewhere on the disk, and if the wrong path is searched for a file name it will not work. How many applications have you tried that failed even though the file was installed somewhere? When an application requests a file, the file system shouldn't care about paths - just find the file in the index. If we cache the search, ls -l /bin can still be made to work like normal. We can do the same with links, so why not with a saved search? An interesting approach would be to use a Bayes filter to put files in the right search folder. Starting Kontact will imply opening a number of additional files as well as the executable. The Bayes filter could for exampel sort started executables into /usr/local/bin, then additional files required into /usr/local/lib based on their behaviour. Virtual folders or saved searches are available, let the computer do the sorting and finding after the initial setup.
• Conary uses branches and changesets like in GNU Arch, marrying

a revision control system to a packaging system. Highly interesting approach!

Users World

• How to protect download users from bad RPMs. We have to maintain a download count and user comments for each RPM. That way download users will know what risk they are taking by installing an RPM for the first time or without a positive comment. Yes, we'll also rely on the downloaders' good faith to provide good comments.

• From a users perspective we need 2 repo's recomended and not-recomended.
  • In the first you put all that is standard for a certain distro. That is the safe choice.
  • In the untested you put everything else, untested and tested but of a different version as the standard. An example. With recomended, you will run KDE that comes with your distro. All aplications that are in recomended will work with that KDE version.
  • In not-recomeded you will have a newer version of KDE and applications available there might not be working with the standard KDE that came with your distro. It would also contain un(sufficiently)-tested software. It is a bit of: run at your own risk. From a programmers point of vieuw I understand the 3 different repos, from a users point of view, two is more then enough and just one would be ideal.

• You need services around it, not just offering http and ftp download of RPMs: managing dependencies is quite a tedious task when you can't use YaST2, apt, yum or red-carpet. Maintaining that repository metadata isn't such an easy task.

• A webbased package system (software warehouse) with "feedback" system could provide with a set of packages that are tested and verified and others that are not. That way any package could be allowed and the feedback would determine the "status" of a package (experimental, stable, untested, testing). This status could be worked into a modified Yast which would take input from whatever status the user decides to allow. This could also be purely webbased as http://klik.atekon.de/ shows or other distro's like Linspire (Clik'n'run). We just need to add a Clik'n'package for developers and have a winner. Brainstorm on this on SUPER KLIK.

• The way I picture this is, the core OS (kernel, shell, utilities, drivers etc. + the base desktop system) is still RPM managed and can be updated, if desired or needed, via YaST Online Update. But the add-on applications use a more user friendly, if possible less distribution and distribution version specific packaging.
  • Why has this to be tied to package classes like stable, unstable, testing? Why cant you just do that for every single package?
  • You can even have more criteria:
    • submitted for the first time
    • downloaded N times from download.opensuse.org
    • installed N times on SUSE Linux (would need some "opt in" monitoring app)
  • What would be nice, regarding that, is to have the possibility of letting users post their experience with the packages through some web interface. When an "unstable" package has a certain amount of positive feedback from users, it's being promoted to "stable". And "testing" packages simply get promoted to "unstable" when they have been reviewed by at least 1 or 2 experienced packagers. IMHO it's a very good solution to a number of potential issues, but most probably involves writing some software for it (the web frontend for posting feedback).
    • list all reported bugs concerning this package
    • number of bugs submitted
    • number of bugs resolved
    • number of bugs pending
    • what other users think of this package
    • the package is 10 (high quality) .. 0 (bad quality)
    • comments on the package
  • Actually you finally should not decide on such numbers whether you install a package but find out to whom packager you can trust or even to whom person can you trust if he tells you that you can trust to a specific packager. Finally there will never be a technical solution that gives you a definitive answer whether one person that looks smart is really smart or whether he is just very excellent in doing self-marketing without having any technical clue. But the fact that SourceForge is so popular shows that the concept of open contribution actually works. They host crap as well but nobody cares because everybody is free to download there what he likes and leave the other stuff alone. Nobody can tell you now definitelly how this concept works out for openSUSE but I consider trying this as being a very refreshing idea. Finally it all depends in how smart SUSE users are. We will see...

• Fast development and an easy uplad policy would satisfy both the commercial need of Novell and also the need of the community to have a large amount of packages, even if they are "experimental" and provide with an answer to other distro's like Ubuntu, which have a similar model - 1 CD - experimental stuff - user friendly) and large debian based repository at the back. This would be a very exciting distro with low entry barriers for packagers and certainly attract all sorts of packagers from other distro's who finally could get their idea into a distro instead of following the more traditional Top-Down model. Non elitist and open to the public satisfying both the need of the Linux community for an experimental approach and the commercial reality with a stable solution.

• The Zero Install System

Sometimes, thinking outside the box is required to find fresh solutions to current problems. Please read the documentation, think through what is written about the security model, and try the supplied SuSE 9.3 rpm. Argument from authority (i.e. invalid if you don't consider him an authority): Tim Berners-Lee likes it, but he is wrong about the need for constant connection, as downloads are cached.

• • Anyone can install software
    • You don't have to be root just to install a word-processor.
  • Anyone can distribute software
    • You don't need to be blessed by a distribution (or anyone else) to be part of Zero Install.
  • It doesn't matter whether software is installed or not
    • You just run it. Zero Install handles the rest (downloading and caching as needed).
  • Downloads are shared
    • If one user installs a 20 Mb application, another user can run it without downloading it again.
  • Users don't need to trust each other
    • If one user downloads a malicious program, other users aren't affected.

• Many people would not be comfortable with the prospect that packages from random people are committed without any review process. Quality is important. Thus I would like to see a group of people, people who have shown to have competence and commitment to review packages before they are commited. This is a good way to hold up a minimum of quality, ensure that SUSE's packaging policies are followed, etc. I see quality here more imporant than the number of rpms.

Packages

• All packages or only a selected few packages?

• Thats exactly what we should try to find out together! Is there an other way were it is still possible to maintain a high quality?

• IMHO, it's a better situation for the end-users to have a little less well-maintained packages than every single project out there but with RPMs that end up in slaughtering your system.

• We need to create a section on the opensuse.org web site where enthusiasts around the world can upload product RPMs for SUSE.

• Since packages are the building blocks of a distribution the way packagers deal with packages will intrinsically define how and how often in what format/quality users will receive packages. The user perspective is very crucial to achieve a usable package system from a developer and from a users perspective. Ideally the "user" view of packages and the "developer" view of packages should be consistent and coherent and just be a different view of the same thing as opposed to 2 different systems coesting with each other.

• What I would like is to have pro-active looking for RPM's. e.g. look at the rss feed from freshmeat.net. If a new files arrives, check if it is already added to the packaging and if not add it. If it is already added, update it. In the beginning a lot would be needed to be done by humans. After a while it would become clear that things could be done atomaticaly.

• The rss feed points to the freshmeat page and already includes licencing info. The freashmeat page gives info about other things and links to RPM/TGZ/CVS files wich could be used

• The main idea is that we need to have a way to pro-active look for things to add to the package. I understand that in the beginning this would need a lot of human interaction, but after a while a lot of parts could be largely automated. If there is a tgz file, downloading and compiling could perhaps be largely automated.

• Another thing which would be cool would be to automatically check other distribuions' bug-tracking systems for patches. The aim would be to make such patches and bug fixes easily available to the openSUSE's package maintainers. Surely they couldn't be applied automatically but having them compiled in a nice list would be very convenient. Isn't Ubuntu working on such a thing in the long term?

• The advatange is that the developers don't have to worry how to be included and we don't have to worry we miss something that is already on at least freshmeat. I could see it working on a semi-automatic basis

• From my experience many packages arenot on freshmeat and often maintainers of packagers are "lzy" and do not update freshmeat very often.

• Check rss for GPL software

	| Is it GPL (or other usable)    -> No -> check next / Also on the page check OS, programming language and the like
	|
   What links are there:
	|________________ RPM -> Use that
	|
	|________________ rpm.src -> Use that
	|
	|________________ tgz, bz2 and the like -> use that
	|
	|________________ unknown -> ask a human for the correct URL

The last could be done by a link to an HTML page where the remaing info
can be added by a humang being. That human is either anybody, or a group
of admins.

• Some programs do not need an update, others might be abandoned and again others might have been summitted, enhanced and the enhancements were never submitted.

• This need to be done by human interaction. Somewhere there would be an anouncement, and then the people who check it would need to decide what status it in. Still working, abandonend or the wrong version. According to each, steps must be taken. If abandoned, perhaps it should be removed (or at least marked as such) if not updated, the link to the correct version must be updated.

• If a package is not actively maintained by the person who is the designated maintainer, it should be given to someone else (or tagged as "unmaintained" and a "would you like to join in and maintain that package ? click here..." on a/the website).

• rpms which don't follow SUSE policies are no option. SUSE always standed for high quality. I don't expect Novell to change this. Thus there MUST be some QA process before (of course afterwards too) any package is added at all. Don't just grab random crap and add it. SPECS need to be reviewed before they are added, packages need to be tested, it must be ensured that even with add-on packages updates to newer SUSE Linux versions are possible, it should be ensured that someone is willing to maintain the package and updates it if a security issue is found, etc. Otherwise you end up like Ubuntu's universe with a big number of packages but not enough maintainers, a lot of broken packages, no security support, etc. We don't want this, do we?

• But review is not enough, as unmaintained packages are a pain as well. People who contribute RPMs must understand that;
  • they must follow a common style guide
  • they become the maintainer for that package and must commit to keeping it up to date and applying bugfixes

• We need to avoid a large sum of packages handled by a small sum of people.

• This problem can be seen for example on Ubuntu's universe. They have 20 maintainers, and about 8000 packages or so. No wonder they are not able to get universe into good shape for Ubuntu's release. This is a very big bottleneck.

• What if the package was clearly marked as untested, submitted by an unknown, unrated, untrusted new user, and not available through automatic update, but only with explicit manual intervention? Would you still object?

• Trust is an issue. But keeping everything out and only letting trusted packages is only one possible solution, and one that creates the bottlenecks you can observe in other open projects.

• Another idea is transparency: make clear what level of trust a package has, what kinds of reviews were done, and make sure users know the risks when they download and install something. But allow everyone to use the build infrastructure and package distribution servers and host their packages there.

• The version of the software itself. Let me pick an example. Package gqview. There are two versions: one stable (2.0.x) and one beta version (2.1.x). Let's say SUSE 10.1 ships gqview 2.0.x, because until now, the policy at SUSE has always been to rather pick the stable version than the bleeding-edge one, which is at least the impression I get from the outside, very understandable and certainly the best choice. Now, during the lifecycle of a distribution version (say, 10.1), SUSE is "only" providing updates for its packages when there's a security fix, or maybe sometimes when there's a severe bugfix. I would like to package the latest 2.0.x and 2.1.x versions of gqview. Users who want to stay on the safe side of things pick the 2.0.x one, and those who want to give the latest bleeding-edge version a try want to pick the 2.1.x version.Unfortunately, apt, yum and YaST2 don't really support that kind of things. If someone adds my repository into, say, YaST2 and refreshes the sources, he'll see that there's a gqview 2.1.4 available, but he won't see gqview 2.0.18.

• Its a quality label of a whole "package set". The problems is see with this approach are: Who controls what is in these package sets? A small group of people like a technical board? Does Novell engeniering do? How do you decide "package sets"? Does the technical board have a look at the individual packages? Or do you just trust some maintainers? You see were that gets you at? It takes away the power from all people and puts that into the hand of some.

• Package checks. They're not even worth a piece of what a review by an experienced packager is. Scripts that make sure that:
  • KDE packages are installed into /opt/kde3
  • GNOME and GTK2 packages are installed into /opt/gnome
  • configuration files are marked as %config
  • packages with daemons include init scripts
  • documentation files are marked as %doc
  • a .desktop file is included/added when appropriate

• Part of it is possible, but not everything, unfortunately. What is possible:
  • build properly on all "supported" architectures (most specifically, x86_64)
  • the dependencies are all included and correct (**)
  • %suse_update_libdir and %suse_update_config are included when it's using autoconf
  • %suse_update_desktop_file is called when it includes a .desktop file
  • include fully-qualified paths to sources (with a few exceptions) (*)
  • correctly split into subpackages, at least when there are some files like include/*, lib*.a, lib*.so (with a few exceptions) (*)
  • no files are installed under /usr/local
  • init scripts include an "rc"-symlink in /usr/sbin or /sbin

• We're having some inconsistencies that are really problematic if you want to use all the repositories, most notably:
  • conflicts in package names
  • conflicts with suddenly appearing SUSE packages, that are sub-packaged and named differently from what we've been providing
  • duplicates: packages that are in more than one repository

• 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.

• How do we now get a specific package into the distro (from the "Creating new packages in openSUSE" thread)?
  • There isn't an "official guideline", as we don't have the storied "openSUSE build infrastructure" in place yet. For now the only way to go would be to file an enhancement request in bugzilla an attach your specfiles to it. If we like the package and want to have it in SUSE Linux, we might take up your work, review it and put it into in. Note: This is the current way to go - this will change dramatically in the future.
• Having a lot of packages (without allowing redundant packages) would be good, even if some of them are not as properly maintained as they could be. I would rather have 3 ISOs of very properly maintained software + 4 ISOs of averagely maintained packages + 4 ISOs of sparringly maintained software than just 3 ISOs of very properly maintained software. I feel that allowing relatively unused packages into the distribution would be benefical, at least better than not including them at all. I don't see any reasons why the quality of the "3 ISOs of very properly maintained software" would diminish by allowing the rest of the packages into the distribution. In this case, if a package is poorly maintained, anyone should be allowed to contribute and help improve its quality.
• We could use tools similar to Debian's popularity contest to decide how to place our RPMs in our ISOs (probably marking the less important ISOs as "additional" or "optional").