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

[Mageia-dev] Mirror layout, round two

+ Michael Scherer + misc at zarb.org +
+ Tue Nov 30 04:47:25 CET 2010 +

+
+ +
Le lundi 29 novembre 2010 à 15:56 -0500, andre999 a écrit :
+
+> Isn't choice part of 
+> what Linux is supposed to be about ?
+
+No. 
+
+That's freedom of the source code, not choice. Reread either Gnu
+manifesto, or Linus Torvalds biography.
+
+And so, you are free to use the source code for what you want, period.
+
+> I think that one advantage of using the mirror structure is that it is a 
+> sandbox that makes it clear to everyone (packagers, maintainers, current 
+> and potential users, qa, etc) what is officially supported and what is not.
+> It has largely worked for Mandriva.
+
+No.
+See the various example I gave. You are not even a packager, how can you
+speak for them by telling "it is clear to everyone" when several
+packagers have expressed that it is a mess ?
+
+
+> What didn't work is
+> (1) the lack of a well-defined and applied criteria for what is to be 
+> officially supported, and
+>
+> (2) the lack of a clear applied policy and strategies of how to deal 
+> with possible dependancies of supported packages on non-supported packages.
+
+The policy was always clear. Main is self contained. This was enforced
+in 2006 with the use of iurt to build rpm.
+
+Every policy of mixing package from main or contribs would be too
+complex from a technical point of view, unsafe from a security point of
+view, incomplete from a QA point of view and a blatant lie for people
+telling "this software is supported" while it depend on unsupported
+components.
+
+> Without this sandbox, packagers are much less likely to do what is 
+> necessary to ensure that supported packages are fully supported, 
+> including dependancies.  Including getting the necessary support from 
+> others to achieve this.
+> Support is much more than an official maintainer.
+>
+> The supposed advantages of discarding a set of repositories over having 
+> an obvious sandbox aren't clear.
+>
+> Another mechanism allowing the end-user to select only supported 
+> packages will be at least as complex.
+> There will be no difference for mirrors.  (Same size, just a few extra 
+> directories.)
+> Packagers can't help but notice if accessing dependancies outside the 
+> sandbox.
+
+Are you sure you have a idea on how packages are built at Mandriva or on
+various distributions ?
+Because right now, what you say doesn't make sense to me, and I can
+guarantee that I know how it work.
+
+> > [ stormi's example ]
+> Excellent example.
+> This also points to the advantage of a mirror-based categorization.  
+> Support should only change by release, not stop somewhere in between.  
+
+This is distribution made by volunteers. If no one want to do the job,
+then the job will not be done. So if no one want to maintain something,
+what should be done ?
+
+And if someone want to do the job, the only thing he has to do is to
+become maintainer.
+
+So no, the example is not "excellent". It is based on a single important
+change : "someone will step to maintain it", while in my example, I
+precisely pre-supposed the contrary.
+
+So the comparaison is totally invalid and misleading.
+
+
+-- 
+Michael Scherer
+
+
+ + + + + + + + + + + +
+

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