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

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.
+>
+> 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 :)
+-- 
+André
+