Op zaterdag 19 februari 2011 14:59:46 schreef Michael Scherer: > 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.
if there is obsoletes, i don't think a question will be asked... > > 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. well, it's an idea, that allows us to have all the functionality we want, and no manual intervention needed anymore.
