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

Thomas Backlund tmb at iki.fi
Sun Feb 20 19:48:04 CET 2011


Michael Scherer skrev 18.2.2011 15:42:
> 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.
>

It is an abuse yes,
but the great thing about it is we _know_ it works...
so no surprises...

(if it aint broken...)

> 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 ).
>

Well, the old simple logic works...

lets say we "abuse" the release tag, for example changing "mga" to "mgt"
then if the user enables "tainted" (meaning he/she wants the rpms) urpmi 
will automatically get the "mgt" ones, no questions asked...

simple, and effective.

and since the rebuild should be automatically on our bs, the versions
will stay in sync.

> But you are right this another set of issues to solve for dual life
> packages.
>

I'd say go for the setup that we know works for Mageia 1, and re-evalute 
the issue after...

--
Thomas


More information about the Mageia-dev mailing list