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 16:07:51 +0200
  • Message-id: <431DA2B7.90902@xxxxxxxxx>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sonja Krause-Harder wrote:
> On Tue, Sep 06, 2005 at 02:15:50PM +0200, Pascal Bleser wrote:
...
> Having a central place to build package in clearly defined build roots
> and with the whole armada of automated package checks during and after
> build is a first step towards quality packages, don't dismiss it too
> lightly ;-)

I do. I can't see anything of that at the moment, so I cannot make assumptions about it.
And as far as the "armada of automated package checks", I believe 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.

I agree that a certain number of things 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

(*) not being done by SUSE at the moment, at least not before 10.0
(**) I have a few rants about SUSE .spec files about that but I would digress ;)

>>> What would we need for such a model to work?
>> 1. define policies and quality guidelines for packages, based on what Novell/SUSE already provides:
>> http://ftp.novell.com/pub/forge/library/SUSE%20Package%20Conventions/spc.html
>> 2. set up an infrastructure for
>> - bug reports
>> - voting/feedback on packages to promote from unstable to stable
>
> 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 ?

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

Sonja, this is a totally different approach you're proposing there, and I really don't know how
viable that would be.
To me, what you're talking about is layered "on top" of what I'm talking about, in a sense that my
feeling is that it doesn't address a number of "low-level" issues like:
- - who's in charge of a package => keep an eye on new releases, keep an eye on security fixes,
contact person for feedback
- - 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 ?

Please develop some of those ideas.. are you thinking of adding that behaviour into YaST2 ?
(maybe it's just too hot, or me being stupid, or all of this being so different of the way I've been
contributing RPMs to a lot of people since quite some time that I can't picture it)

> 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 contolling very few of
> them. Would that meet your requirements?

I don't know. This is really too abstract at the moment.
We'd need to discuss it a lot more.

> Let's think further than the Debian model, please.

Call me small-minded, but we're not even near something as the Debian model at the moment.

Let me put this back into the current situation.

We're a very small number of "3rd party packagers" (packman, James [Ogley], a few suse-people, a few
suser-* on gwdg.de, and my site) and we're only partially talking to each other, packman definately
being the most consistent repository (as well as the largest), as it already groups a small number
of active packagers (and thanks to the hard work of Marc Schiffbauer and Eberhard Moenke, without
whom we as a SUSE community wouldn't even have that).

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

Sonja, I'm probably not seeing the "bigger picture" like you do, but those are concerns we're
currently having, partly because we have not been much integrated or supported by SUSE up to now
(please don't take that as a rant, and I know that some devoted SUSE employees have always been easy
to contact and discuss such issues with).
And, yes, that's why there's openSUSE now, and it's great, but I'm still kind of lost on what's
really going to happen with regards to the community's packagers.

If we don't even put up something to address the 3 issues we're currently having now, how do you
want to make that very new and shiny concept (no, that's not ironic ;)) reality ?

Maybe I'm too focused on centralizing a certain number of things, because most of the problems the
Packman packagers and I have at the moment are directly related to the fact that we're all loose and
uncoupled.
And we're just a few. If I imagine all this exploding into a large number of packagers, most not
having been through what we have, I don't really see another outcome than having a large number of
RPMs all spread around, not compatible to each other, massive conflicts, possibly poor quality
packages, and all that being broken down onto the users.
(<rant>hmm.. does that sound like Fedora ? ;)</rant>)

IMHO, quality and consistency has always been the major asset of SUSE Linux, and the small number of
3rd party repositories its biggest issue.
I don't think that sacrificing the first to improve the other is a good option.
But maybe that's just me. Or maybe we'll find a way to combine both.

<blatant-self-promotion>
Let's all meet at FOSDEM 2006 in Brussels, make a big openSUSE developer room and talk about all
that, and we could even have some people from Debian, Fedora, Ubuntu, Gentoo or whatever join in ;)))
</blatant-self-promotion>

cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <pascal.bleser@xxxxxxxxx> <guru@xxxxxxxxxxx>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFDHaK2r3NMWliFcXcRApgAAJ9QYqQfUFmVwHxs9wtr0eG8cG1kdQCfeBca
uSeBproE+/j2LlftJWosIQA=
=ThrG
-----END PGP SIGNATURE-----

< Previous Next >
Follow Ups