[Mageia-dev] Mirror layout, round two

[andre999]

nicolas vigier a écrit :
> On Mon, 29 Nov 2010, andre999 wrote:
>
>    
>> 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.
>>      
> I don't think we need repositories to define bug priorities. If a
> package break the system, the bug report should mention it. And we can
> also have minor bugs in "core" packages not breaking anything. Should
> we fix them in a timely manner, before any critical bug on "extra"
> packages breaking useful applications ?
>    
I agree that minor bugs in core need not have absolute priority.
But from what I see, few bug reports mention that something "breaks the 
system".
They focus on the issue in question, to varying degrees of success.
(Reminds me of end-user support.  Much of the time they don't recognize 
the real problem.)
My point is, significant bugs in core packages should be fixed in a 
timely manner, as much as possible.  And indeed, critical bugs should be 
fixed.  But if a critical bug affects a non-core package, it is likely 
to affect only that package.  Not so a core bug.

By core, I mean in the logical sense.
If that can be done effectively and efficiently with a set of "core" 
repositories, so be it.
However I don't see such a solution.
I would very much prefer to continue with the present separation until 
such a solution, if any, is found.
And the cost of separate "core" and "extra" repositories is minimal, 
assuming that core packages are officially supported.  And separate 
repositories do provide benefits to end-users, as well.
>>>    - 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.
>>      
> Why do we need two repositories for that ?
>    
Sandbox.
It is clearer to everyone.
The fact that Mandriva didn't control what went into main is a large 
part of their problem.
If you can find another solution, just as reliable, great.
But I suspect it would be more complex, and probably cost more in 
resources as well.
The cost of extra repositories is almost nil - if we assume that we want 
to rigorously control what is to be fully supported, and apply it.
>>>    - 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.
>>      
> Suggests on BuildRequires does not exists. And we need them to be
> installed for the build.
>    
If a core package has real buildrequires, then these requires should be 
in core.
If only a non-core package has buildrequires, these requires need not 
necessarily be in core.
Although packages like cmake should probably be in core anyway, as they 
are very likely to be used to build packages.
I don't know details for rpm5, but it could have the equivalent of 
suggests for buildrequires.  (Like an alternate list of tools required ?)
Alternately, maybe some modification will have to be done to the spec files.
Since Mandriva is going through a very similar process, we could 
probably share much of the changes required.

By the way, for the conversion to Mageia, I would suggest assuming that 
all of main + contrib is in extra, and moving those to core which meet 
our criteria.
Much of main will be very quickly moved, such as base Linux/Gnu 
packages, drak* tools, etc.
And selected applications like Go-oo/LibreOffice and Firefox.
We will first have to detail our criteria, of course.

another 2 cents :)

- André