Mailinglist Archive: opensuse (4398 mails)

< Previous Next >
Re: [opensuse] Packages from a user and Packager perspective
  • From: Pascal Bleser <pascal.bleser@xxxxxxxxx>
  • Date: Tue, 06 Sep 2005 17:34:47 +0200
  • Message-id: <431DB717.6020104@xxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sonja Krause-Harder wrote:
> 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.

Ok. So you actually mean: central hosting on opensuse.org + the current build infrastructure SUSE
has (=> the build servers).

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.

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

See, you're coming back to the things I've put up for discussion ;)
Fine, let's talk about a whole new approach, package sets or whatever we'll find out to be an
interesting and realistic concept, but let's keep in mind the "low-level" issues we need to solve.

>> 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 ;-)
Seems so, indeed ;)

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

I already mentioned that extensively, as well as stressing the need for a "policy" and "guidelines".
Now, what was so wrong with what I wrote in my previous mails ? ;)

>> - - 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.
Yes, I agree that this is the very obvious approach. Makes sense.

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

How is that so different from the current situation ? (besides enhancing YaST2 to use such "package
sets" (= installation sources) with more ease)

We currently have such "package sets", at least:
- - packman
- - suser-*
- - suse-people
- - my site

What's so different in a "package set", compared to an "installation source" ?

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

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).
But both versions cannot be installed side-by-side, unless you do some really, really heavy patching
that costs a vast number of hours of work (been there, tried that already, abandoned).

I don't see how "layered package sets" would solve such issues, neither how we could build packages
that solve issues that are originally flaws in the software itself (or how it installs itself).

But I agree that this is the kind of problem you're also getting into with the "Debian approach".
Installing gimp-2.3.0 would mean upgrading half your distribution's packages.

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

Probably so, yes.

- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v ===> FOSDEM 2006 -- February 2006 in Brussels <===
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDHbcXr3NMWliFcXcRAl1SAJ0WPNQSZg9dvbBXpoLSDlpF839sAQCfc0kA
gTeSTeN0rh7spLTTwr2Jzj4=
=7Axy
-----END PGP SIGNATURE-----

< Previous Next >