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/001519.html | 146 ++++++++++++++++++++++++++++++++ 1 file changed, 146 insertions(+) create mode 100644 zarb-ml/mageia-dev/20101129/001519.html (limited to 'zarb-ml/mageia-dev/20101129/001519.html') diff --git a/zarb-ml/mageia-dev/20101129/001519.html b/zarb-ml/mageia-dev/20101129/001519.html new file mode 100644 index 000000000..cc03d6acc --- /dev/null +++ b/zarb-ml/mageia-dev/20101129/001519.html @@ -0,0 +1,146 @@ + + + + [Mageia-dev] Mirror layout, round two + + + + + + + + + +

[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
+ -- cgit v1.2.1