[Mageia-dev] Mirror layout, round two

andre999 andr55 at laposte.net
Mon Nov 29 19:57:39 CET 2010


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é


More information about the Mageia-dev mailing list