[Mageia-dev] rehashing the faac issue

Wed Oct 31 02:48:21 CET 2012

Johnny A. Solbu a écrit :
+> On Tuesday 30 October 2012 09:30, andre999 wrote:
+>>> The problem of including nonfree spftware in tainted, is that it
+>>> no longer is a Free software repo in countries that don't accept
+>>> software patents.
+>>
+>> So how is that a problem ?
+>
+> I am one of those that have core and tainted activated, but not
+> nonfree. I know that every available package urpm can find is Free
+> and open source software. If we start to include nonfree packages in
+> tainted, one can no longer activate tainted and be sure that every
+> package available for instalation is Free software.
+>
+>> Would it help if a user could set a configuration to automatically
+>> control the installation of non-free packages. Something like
+>> "never", "confirm each time", or "always", similar to what has been
+>> proposed for isos ?
+>
+> If it also works with urpm in the terminal, yes it's a help. I never
+> use the graphical package management tools to install anything,
+> unless I'm showing a user how to use the system. The only time I open
+> the graphical package manager, is to browse through the categories
+> just to see what's there. Sometimes i find cool games this way.
+
+Myself I prefer graphic tools when they accomplish my goal more readily, 
+which is most of the time installing packages.  Fewer problems with typos.
+>
+> The «never» option should work with the terminal tools like urpmq and
+> urpmf. Meaning, if one choose to configure it to ignore nonfree
+> packages, it should also not show up in searches. Which is one of the
+> benefits of having separate repos.
+
+My idea is to store such a configution option in the global section (at 
+the beginning) of /etc/urpmi/urpmi.cfg, so it would be available to both 
+console and graphic tools.
+
+>
+>> Don't forget that packages in the tainted repo have to be
+>> downloaded from the net, unlike packages in core or nonfree, which
+>> could be on an iso.
+>
+> That depends. I never install from anything else but a network
+> install. Mainly because i have access to much more software in one
+> go. In the cases I install from a DVD iso it is on behalf of another
+> user, and I usually add a repo anyway. In the past when I installed
+> from a DVD on my own systems, I always added my local repo mirror.
+> (urpmi.addmedia --distrib blahblah)
+
+I was thinking of internet installs -- which are often unreliable (at my 
+location), if installing/updating many packages.  (It seems to depend on 
+the weather, even though I have a wired connexion to internet.)
+
+>
+>> So having an additional control, and using the "never" option would
+>> eliminate any chance of installing a non-free package from
+>> tainted.
+>
+> As would a new repo. :-)=
+>
+>> Wouldn't that work for you ?
+>
+> Yes, for me that would work, but this is not my point. :-)= I'm not
+> making noice because it's an inconvenience to Me, but because if we
+> do this we are thowing out our long standing tradition of separating
+> Free software from Nonfree software.
+>
+If I'm not mistaken, constrained packages tend to be presented elsewhere 
+in a single set of repos, free and non-free together.
+I do agree that the category should be very clearly identified.
+As it stands now, most non-free and many constrained(tainted) packages 
+have nothing in their name to indicate their category.  So if a package 
+is not in the correct repo, there is no easy means to determine its' 
+category.  If we require a tag the package name for all non-free, and 
+similarly for all tainted, we would loose this ambiguity.
+Note that if urpmi is configured to keep downloaded packages after 
+install, all packages, whatever their category, whatever release, are 
+put in the same directory.  Putting a tag in the name would remove the 
+resulting ambiguity.
+
+Besides the extra overhead, the thought of another set of repos with a 
+configuration to maintain is not inviting.
+It wouldn't be so bad if configuration were presented in a grid instead 
+of an endless list, at least for official repos.
+If the presentation were simplified and a way found to minimise any 
+overhead, I'm not necessarily against an extra set of repos.  But having 
+to scroll down a few pages to review the configuration, or select among 
+a dozen repos every time one updates, is a pain.
+
+-- 
+André
+