nicolas vigier a écrit :
On Mon, 29 Nov 2010, Samuel Verschelde wrote:
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. And remember that the proposed restriction for core was those
packages necessary to a typical desktop or server or development system,
plus a *few* very useful/widely used packages such as LibreOffice
(OpenOffice) and Firefox.
Suggested to be included was "complete desktops", which would be
somewhat subjective as well.
Outside of these potentially controversial borderline cases, what would
be in core would be well defined.
We don't need separate medias to show that there are two sets of
packages, supported and unsupported. I think using separate medias adds
useless complexity.
If we look at our origins, we are not adding media here.
But we are limiting what is in "core" (main).
Note that in their reorganization, Mandriva is moving in the same direction.
I see this more as a refocus of the packaging process, much like the
(very useful) addition of backports_testing.
We could for instance provide a file on api.mageia.org
containing the list of officially supported packages. It would also have
other advantages :
- You can see how many unsupported packages and which ones are installed
on your system. This is not possible with main/contrib, if you enabled
contrib temporarly to install a few packages.
This is not really related to one or 2 groups of repositories. Although
doing that for *officially fully supported* packages should be
moderately easier with separate groups.
Note that many packages in "extra" would also be very well supported, by
the packager or official maintainer.
The idea is not that the Mageia community would not support "extra"
packages.
It is just that if an "extra" package breaks, it shouldn't break a
user's system.
But if a "core" package breaks, we would expect that it would break many
users' systems.
Thus the priority to ensure that "core" packages are always fixed in a
timely manner.
- You can change the package status (supported/unsupported) after the
release, if needed.
If the division is well defined, we should rarely need to change a
package's status.
There will be many well supported packages in "extra".
- Some packages can have a different support time. On Mandriva, "Base
system& components" was supported longer, but it was not clear which
packages were part of this.
Core is proposed to be largely "base system & components". Part of the
idea is to make clearer, to everyone, which packages have an enhanced
level of support.
Support time is another (useful) question.
- This file could also list known security issues for unsupported
and supported packages.
Not related to the core/extra question, but a useful feature. For
Mageia-app-db project :)
- Some packages have a lot of optional plugins, and we build them all,
adding a lot of build requires. With main/contrib separation we need
to add all the build dependencies to main, even if most of them are
not runtime dependencies.
We will have to be more selective for core packages, to avoid this problem.
Maybe "suggests", or other features being added with rpm5.
I would agree that, at least in the transition, this would make more
work for packagers.
But in the longer term we will have a much more stable system.
I see this as one of the key advantages of this "core" / "extra" separation.
(Hopefully we will also get rid of annoyances such as requiring everyone
to install thai localisations.)
(Note that Mandriva is moving to rpm5 for their next full release
(proposed for May 2011), which has more features for building rpms.
Presumably Mageia will follow.)
- André
