[Mageia-dev] About panotools patent problem (and other problematic rpms)

andre999 andr55 at laposte.net
Tue Feb 22 19:09:17 CET 2011

Maarten Vanraes a écrit :
> Op vrijdag 18 februari 2011 14:42:02 schreef Michael Scherer:
>> Le vendredi 18 février 2011 à 12:47 +0000, James Kerr a écrit :
>>> If there are two packages, one in core and another in tainted, then
>>> doesn't urpmi need a way to recognise that the tainted package is newer
>>> than (an update to) the corresponding core package? I believe that this
>>> is achieved in Mandriva, because plf is greater than mdv.
>> That's abusing release tag and it work by pure chance ( ie, had the plf
>> decided to  be called the guillomovitch liberation front, it would not
>> have worked ). And this is quite inflexible, since people will always
>> have plf packages, leading to users adding some rpm in skip.list with a
>> regexp.
>> This doesn't make much sense to treat tainted rpm as update to core,
>> this is not the same notion. But we cannot express this in urpmi for the
>> moment, as this would requires some way to say "if you need to install
>> something, prefer this source rather than this one".
>> We can imagine a priority system, or we can simply say that if there is
>> the same rpm on 2 media, we ask to the user ( except this would requires
>> IMHO a better system than the current path based one to see what is in a
>> rpm, but that's a rather long proposal to make ).
>> But you are right this another set of issues to solve for dual life
>> packages.
> after sleeping on this, i've had this idea:
> why don't we rename packages in tainted?
> keeping them in the same name, perhaps has issues with search engines, (ie:
> which version do you get?)
> i proposed renaming packages in tainted,(but not the release tag).
> would it be a good compromise if we named packages:
> <orig_packagename>-tainted-<version>-<release>  ?
> the benefit of this could be adding an Obsoletes and Provides on the original
> package with the identical version.
> for building, i may have this solution:
> %tainted(%_optional_feature1 %optional_feature2 %optional_feature3)
> this would allow the buildbot to look for %tainted  and if it does, it could
> rebuild it for tainted and add the particulars itself. this would simplify the
> whole plf/tainted thing easily. and since all 4 rpms are being built at the
> same time, you have no srpm problem either.

First of all, "tainted" in English implies that the software doesn't 
work.  (Unless it refers to food, in which case it means "poisonous".)
So we should choose a more appropriate name, such as "constrained", or 
use the Ubuntu approach and use a name which doesn't literally describe 
the contents. ("Multiverse", in their case.)
Anything but something that implies that there is something inherently 
wrong with the package in question.
That was one advantage of "plf", but of course that is already taken. 
And it is certainly advantageous to include such packages directly on 
Mageia mirrors.

A Cleaner approach -- albeit more work -- would be for the "constrained" 
package to be an external module which adds the missing functionality. 
For less modular packages, this would be replacing (only) the files 
which provide the questioned functionality.
For a typical a music player-type application, this would be only a be a 
few relatively small files.

So a user that wants to add the "contrained" functionality would simply 
add an extra package, which obviously would have a different name based 
on the main package.
(It would be useful to suggest adding such packages during installation, 
if the "contrained" repositories are selected.)
(That is, if such a related package is available in selected repos.)

Think of the gstreamer packages -- the "ugly" perhaps corresponding to 
the "constrained" packages being considered.

my 2 cents :)

More information about the Mageia-dev mailing list