[Mageia-dev] rehashing the faac issue

andre999 andre999mga at laposte.net
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é


More information about the Mageia-dev mailing list