[Mageia-dev] Mirror layout

Fri Dec 10 17:37:07 CET 2010

On Friday, 10 December 2010 16:35:09 Wolfgang Bornath wrote:
+> 2010/12/10 Buchan Milne <bgmilne at multilinks.com>:
+> > easyurpmi should not be necessary. Users should not be expected to paste
+> > random commands from random sites into a root shell.
+> 
+> Yes, if urpmi were able to switch from one mirror to another one in
+> case of any failures or at will of the user if the automatically
+> selected mirror is too slow. An issue discussed often enough since
+> Mandriva days (also reported as bug). Until this is not solved users
+> are sometimes (in germany more often than "some times") forced to use
+> such tools like easyurpmi or smarturpmi.
+
+But, the user can also have problems here (if the mirror is too slow, if it is 
+behind, if it isn't maintained and users are *still* vulnerable to "rogue 
+mirror, keeping old vulnerable software around" issues).
+
+> > Alternatively, the whole dichotomy that necessitated contributors to
+> > create a separate project should be addressed differently, but keeping
+> > the packages integrated into the distribution, but avoiding legal issues
+> > by making it easy for entities hosting the files to avoid infringement.
+> 
+> Isn't this what this whole discussion is about? There ARE legal issues
+> with some software users regard as "must have". Now, how do you avoid
+> these issues?
+
+IMHO:
+-split the software so mirrors have an easy method (e.g. rsync --exclude 
+'*/*/*/tainted') of avoiding software that may be risky for them to distribute
+-make the mirror list api support the user submitting the repos names they 
+want to use (e.g. if I ask for tainted, give me a mirror for tainted, even if 
+'non-free' is on a different mirror)
+-expose these options in the GUI, and possibly use sane defaults (possibly 
+even by region)
+-improve automatic mirror switching in urpmi
+
+IMHO, media.cfg is more useful for initial (network) installation, and the 
+case where the user trusts their mirror.
+
+> This is the big question we have been talking about for
+> many days.
+> 
+> >> Many if not all of which were in PLF for patent reasons, according to
+> >> the package description.
+> >> Which brings up a difference of PLF packages : the PLF description
+> >> usually ends with a line specifying why they are there.  (At least
+> >> packages destined for Mandriva users.)
+> > 
+> > Search for plf in e.g. http://svn.mandriva.com/cgi-
+> > bin/viewvc.cgi/packages/cooker/ffmpeg/current/SPECS/ffmpeg.spec?revision=
+> > 612098&view=markup
+> 
+> Ah, does that search really give results? It should not because
+> Mandriva always stated (officially) that they have nothing to do with
+> PLF. I remember discussions where Mandriva representatives said that
+> Mandriva can not acknowledge PLF's existance.
+
+Mandriva was subverted :-).
+
+Anyway, what difference does it make, whether a possible patent-infringing 
+feature is provided in the source, or enabled by a --with flag doesn't change 
+much. Unless Mandriva was going to actually remove patent infringing code in 
+the tarballs before committing to svn ...
+
+However, Mandriva packages do *NOT* in the meta-data shown to end-users 
+indicate anything about PLF. As such, complaints about linking to infringing 
+software are invalid.
+
+> BTW: there are important differences between Mandriva packages and
+> those built by PLF. Especially such as mplayer and vlc, with reasons.
+
+Of course, but the majority are not *duplicated* from a software maintenance 
+perspective, that would be a waste of time.
+
+Regards,
+Buchan
+