-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Henne Vogelsang wrote:
On Tuesday, September 06, 2005 at 13:48:25, Pascal Bleser wrote:
Henne Vogelsang wrote:
On Tuesday, September 06, 2005 at 12:58:43, Pascal Bleser wrote: Im sure there are more ways to talke this problem. I myself find the "quality over quantity" approach not to good. I does not fit into my understanding of "open". And thats what we want to be. openSUSE not somepeopledecidesomenotSUSE.. Henne, who is deciding on what's going into the SUSE media or into the ISOs ? ... see ;) Well thats not carved into stone...
Nice to hear so ;) ...
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.
You see? Thats what im talking about. Why has this to be tied to package classes like stable, unstable, testing? Why cant you just do that for every single package?
Because to me, IMVHO, 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.
But there's also another aspect: the version of the software itself.
Let me pick an example.
I 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.
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 (<personal-rant>because, as we know, GNOME libs are sooo
backwards-compatible</personal-rant>).
But then again, if I want to package the latest GIMP and I require the latest GTK version for
that... well, I'll just have to put my package into the "unstable" repository, where the latest GTK
version is in as well.
Now, to get back to that idea of a "quality label", it's more or less the same thing.
What's really difficult to handle is the dependencies between packages that are not in the same
repository - although having dependencies towards packages that are in "stable" or in the stock SUSE
distribution is not an issue at all.
Note that you're all ranting on what I say and beating me up in every reply, but up to now I'm the
only one proposing concrete implementation ideas ;P
So, if you have better ones, go ahead =)
Henne, how do you want to implement "Why cant you just do that for every single package?" ?
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\