Samuel Verschelde a écrit :
Le lundi 29 novembre 2010 17:08:25, Michael Scherer a écrit :
Le lundi 29 novembre 2010 à 15:24 +0100, Samuel Verschelde a écrit :
Le lundi 29 novembre 2010 14:56:20, Michael Scherer a écrit :
- complexity on the users system as they need to have twice the number
of media to cope with this. This also appear in the interface of
various tools, and it is imho uneeded. Most people will say that we
already have too much medias.
4 instead of 3 is 33% more.
That aside, you're essentially referring to package installer tools
(rpmdrake) for the user.
If we have a separate "extra", and the user chooses to (usually) only
install officially supported packages, the response to the user will be
faster with the extra media, not slower.
Now I deactivate contrib most of the time for faster performance. (It
makes a *big* difference.)
With a relatively smaller "core" (than "main"), we will have an even
greater performance advantage for keeping an extra set of media.
And if the user chooses to keep "extra" activated ? Essentially no
difference.
But you do raise an important point. We do need to improve rpmdrake and
associated tools.
I think that that should be a priority.
However as long as the user is permitted to choose, they will be
presented with choices, in one form or another. Isn't choice part of
what Linux is supposed to be about ?
Indeed, however it helps showing that there's a set of packages which is
supported,
and another one which is only on behalf of the maintainer. In a community driven
distribution, this distinction may remains valid : some packages are officially
supported by the distribution, others may or may not be, depending on the
maintainer
(or lack of maintainer).
Exactly
If there is a maintainer and he has a account, then it is a official
one, and so the package is officially supported. That's all. There is no
separation of "the organisation" and "the maintainers", we are not
Mandriva.
So either the package is supported, and we keep, or it is not, and then
why should we keep it ?
Because it works, at least partially. Because it has users. It may have flaws,
it may not have the latest security fixes, it may just be supported but only
updated once a year... That's not a reason for dropping it. That's why
distiction between officially supported and not officially supported is useful.
There are working packages, seldom updated, which don't deserve to be dropped,
but which can't be advertised as officially supported, and that's
understandable. The world is not either black or white, there are many shades
of grey, and that's particularly true for packages in a linux distribution.
According to what you said, it looks like there will be only 2 kinds of
packages :
- in the distribution (which would be equal to "supported")
- not in the distribution
But we all know that there will be :
- supported, both in cauldron and stable releases (updates + backports)
- supported, both in cauldron and stable releases (updates, no backports)
- supported, in cauldron only : the maintainer only cares about cauldron and
hasn't enough time to fix bugs in (to his mind) old stable releases
- the same, but some people do backports from time to time
- supported in stable releases, but dropped from the cauldron because the
maintainer couldn't maintain it anymore
- has no maintainer, but works, although it may have bugs and security flaws.
Has users.
- many other situations
- not in the distribution
What I'm asking for is that we put dedicated work into ensuring packages
flagged as supported have security and bugfix updates in stable releases.
In Mandriva, you can find many examples of packages in main which are not
supported in reality, or even maybe simply don't work. You can find also many
packages in contrib which are perfectly supported, in cooker as in stable
releases. You gave me examples. However I see very rarely security or bugfix
updates for packages in contrib for stable releases (or sometimes they go to
backports), whereas there are many security fixes and bugfixes for packages in
main thanks to Mandriva's security team. There really is a difference between
supported packages and other, although it's far from perfect.
If there's no difference in term of security updates between php and a random
maintained game, then I won't be very confident in the distribution's quality.
Let's say I want to install php on the stable Mageia 2011, will it be supported for
security fixes and bugfixes ? For how long ? Are security fixes applied as soon as
possible ? If the only answer is "is has a maintainer, so it should be supported
like all the other packages", I'll probably avoid Mageia on a server.
So this time it's not a rhetorical question : is Mageia willing to provide
official support for a subset of the available packages ?
Flagging some packages as officially supported is a matter of putting dedicated
resources and processes to ensure - as much as possible - good quality for
those package. Like I said before, having a maintainer in itself is not
sufficient, we also need support policies and a list of officially supported
packages.
Totally agree.
I agreed that the mirror structure is not the best way to make this
distinction. An external list is good enough for that and can even bring new
possibilities, as Nicolas Vigier stated in another post.
I think that one advantage of using the mirror structure is that it is a
sandbox that makes it clear to everyone (packagers, maintainers, current
and potential users, qa, etc) what is officially supported and what is not.
It has largely worked for Mandriva.
What didn't work is
(1) the lack of a well-defined and applied criteria for what is to be
officially supported, and
(2) the lack of a clear applied policy and strategies of how to deal
with possible dependancies of supported packages on non-supported packages.
Without this sandbox, packagers are much less likely to do what is
necessary to ensure that supported packages are fully supported,
including dependancies. Including getting the necessary support from
others to achieve this.
Support is much more than an official maintainer.
The supposed advantages of discarding a set of repositories over having
an obvious sandbox aren't clear.
Another mechanism allowing the end-user to select only supported
packages will be at least as complex.
There will be no difference for mirrors. (Same size, just a few extra
directories.)
Packagers can't help but notice if accessing dependancies outside the
sandbox.
Of course, if we can find another mechanism as likely to succeed ...
...
Well, everything should be supported or dropped, that's all. Easy, done
by every other distros out there except those that place a artificial
separation. If there is a security bug opened and no one act on it after
a time, let's drop the package. If there is a severe bug and no one act,
the same, let's drop it.
If people want to resurrect a rpm, they can, there is a svn for that.
This is the most terrible thing I read so far.
Sounds like a distro killer policy. But we're just getting started ... :(
I already tried to answer it earlier in this message, however here's a last
example :
- Someone checks if postgresql is supported because if not he'll use another
distribution where it is
- It is (because every package is supported, or it's dropped), but the poor
user doesn't know that Nanar went away doing his own fork, no one stepped in to
maintain it !
- One year later, postgresql has still security bugs opened, no one takes care
=> package is dropped
Now if there were a list of supported packages, either it would not be
officially supported and the user would know he could use it but maybe won't
have security and bugfix updates, or it is officially supported. Now take the
example above :
- Someone checks if postgresql is supported because if not he'll use another
distribution where it is
- It is !
- However the maintainer went away doing his own fork, so he dropped
maintainership.
- Someone in QA Team rings a bell : "this supported package isn't supported anymore,
but we promised we would support it for Mageia 2011 for 2 years from now ! We have to do
something !"
- The package team leader, or someone else, relays the warning and finds
someone else to maintain the package, at least for Mageia 2011, for security
and bugfix updates.
- (another scenario : there is a maintainer, but the package has pending issues
for a long time, so we have to contact the maintainer about it, and maybe find
another maintainer)
The difference is : because we said we would support it for Mageia 2011's
lifetime, we do everything possible to keep this promise, and I think we can
succeed provided the set of supported packages is carefully done. Things will
be clearer, to my mind.
Excellent example.
This also points to the advantage of a mirror-based categorization.
Support should only change by release, not stop somewhere in between.
Maybe caudron uses a list, which could change at any time (in view of
the next release), but users would never expect support to cease
mid-release.
We _already_ do not know what is supported or not at Mandriva. People
push update to contribs ( I do push them for tor or puppet ), while some
packages in main are not updated or buggy or simply unrebuildable ( see
all mdk rpm still in the distro for long forgotten reasons ). See this
old long standing pdftk bug caused by a issue in the java stack in
main : https://qa.mandriva.com/show_bug.cgi?id=44372 . In main, and no
one did anything.
Having packages which ought to be supported and are not in practice doesn't
mean that there must be no difference between officially supported and not
officially supported.
Exactly
There is also lots of duplication :
- apache& nginx, who was moved to main likely because oden like nginx,
- the various ftp servers,
- sendmail& postfix,
- the 4 tls/ssl implementation,
- the 2 html rendering library ( webkit, gecko ) with more than 1
browser.
What prevents from refining the list if it's too big ? Choosing officially
supported packages is a matter of setting priorities, because we have limited
resources. In what way will things be better if there is no list of officially
supported packages ?
Having 2 officially supported equivalents is not necessarily a bad idea
for important functions, as it gives more user choice - like mysql &
postgresql, or webkit & gecko.
However we don't need 47 packages that do almost exactly the same
thing. At least not officially supported. We do have to be selective.
Note that many packages, such as translation aides, alternate text
editors, etc, won't break a user's system if they break. So they would
belong in "extra" in any case.
Regards
Samuel Verschelde
another 2 cents :)
- André