Op dinsdag 22 februari 2011 19:09:17 schreef andre999: > 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. > > > > WDYT? > > <aside> > 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. > </aside> > > 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 :)
sure, but that doesn't always work, not all software is done like this