[Mageia-dev] Mirror layout, round two
misc at zarb.org
Mon Nov 29 14:56:20 CET 2010
Le lundi 29 novembre 2010 à 13:14 +0100, Samuel Verschelde a écrit :
> It was said early that you just have to look at whether the package
> has a maintainer or not to make a distinction, but this is not sufficient.
> A maintainer can be very active in cauldron but not care about maintaining
> for stable releases. A package can have no maintainer but be actively
> supported in practice (by everybody in cauldron, by security team in
> stable releases).
> The current main vs contrib approach in mandriva is very sensible. It has some (minor, to me)
> drawbacks, but when I install packages from main I *know* there will be security updates,
> bugfix updates, and a QA process that packages in contrib don't have.
Since we pull lots of deps ( like perl module, python module ) to ensure
that everything build fine without any formal check of packages, I can
ensure you that packages in main do not have more QA process than
What is checked is a list of functionality in the default installation.
Not every possible feature using every possible package in main.
Almost all community distros have found that what you call "minor"
drawbacks are in fact not a good idea. Fedora merged core and extras.
Debian never did the split, Gentoo either. The split is usually just a
reminiscence of the commercial nature of the main sponsor ( Mandriva,
Let me remind the problems that we are having with the split, as they
are not so minor :
- complexity on build system side to take in account this
- packagers time lost to understand what going on when self
containment is broken. Older ones do not have the problem ( or at
least, know it ), but newer one sooner or later does.
- 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.
- complexity because users do not understand it. If we tell
- time lost managing it. moving from contribs to main, and cleaning
main. Main cleaning that is seldomly done because :
- no one has time to do it
- people fiercly defend the inclusion of their favorite software in
- time lost because packagers have to wait on overloaded sysadmin to do
- complexity over time of support because package move from main to
contribs and viceversa. Especially when there is some backports from
a software in main that would requires a software in contribs, etc.
> Do we plan to have no QA process at all in Mageia ?
You should not use this kind of formulation, this is FUD.
> If we plan to have such processes, does the merge between core and extra
> make is efficient ? I guess we don't plan to have all packages (even
> maintained ones) equally supported with a full QA process (doesn't seem realistic) ?
Again, reread the mail I sent. This is a user concern, not a mirror
admin concern. As such, it should not leak on mirror organisation,
neither on BS organisation.
And the filtering proposal I made could perfectly fit, provided we find
a way to get the "QA note" for a package. Maybe a webapp, with
If some users only want to have only "QA approved package", that's
rather easy. Just install nothing outside of the default set of
> Packages in core get the "QA approved" stamp whereas packages in extra get none.
The self containment requirement would make it very hard to get such QA
We cannot have a package being tested without doing the same for its
requires first. And we cannot say that we support a package without
supporting the full requires.
Look at openoffice at Mandriva. It does requires
tomcat5-servlet-2.4-api, hsqldb on 2010.1 . They are both non trivial to
test, and I am quite sure that they were not much "QA approved" besides
"openoffice work for basic tasks". And in fact, when eclipse was in
main, this was the same.
So in order to have openoffice to have a QA approved stamp, openjdk,
tomcat and hsqldb would have one. I am pretty sure they do not had
More information about the Mageia-dev