On Sat, 19 Feb 2011 09:20:50 +0100, Maarten Vanraes wrote:
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?)
with search engine ?
I can see the issue for support, yes, but search engine, no
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.
This could work, but I am not sure that a Obsoletes is required.
One problem with this idea is that it will ask to user lots of
questions, and that's
something we should rather try to avoid ( any people who installed some
java rpm will
understand the issue ).
But it has the advantage of not requiring anything special on BS while
providing the choice.
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.
A simple %define would do the trick, so that doesn't bring much.
And we can keep a list of package that should be compiled twice, that's
not the biggest problem to solve.
--
Michael Scherer
