From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20101129/001522.html | 150 ++++++++++++++++++++++++++++++++ 1 file changed, 150 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101129/001522.html (limited to 'zarb-ml/mageia-dev/20101129/001522.html') diff --git a/zarb-ml/mageia-dev/20101129/001522.html b/zarb-ml/mageia-dev/20101129/001522.html new file mode 100644 index 000000000..625b736c9 --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001522.html @@ -0,0 +1,150 @@ + + + + [Mageia-dev] Mirror layout, round two + + + + + + + + + +

[Mageia-dev] Mirror layout, round two

+ andre999 + andr55 at laposte.net +
+ Mon Nov 29 22:31:58 CET 2010 +

+
+ +
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é
+
+ + + +
+

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1