From 1be510f9529cb082f802408b472a77d074b394c0 Mon Sep 17 00:00:00 2001 From: Nicolas Vigier Date: Sun, 14 Apr 2013 13:46:12 +0000 Subject: Add zarb MLs html archives --- zarb-ml/mageia-dev/20110219/002668.html | 155 ++++++++++++++++++++++++++++++++ 1 file changed, 155 insertions(+) create mode 100644 zarb-ml/mageia-dev/20110219/002668.html (limited to 'zarb-ml/mageia-dev/20110219/002668.html') diff --git a/zarb-ml/mageia-dev/20110219/002668.html b/zarb-ml/mageia-dev/20110219/002668.html new file mode 100644 index 000000000..9a2b4904d --- /dev/null +++ b/zarb-ml/mageia-dev/20110219/002668.html @@ -0,0 +1,155 @@ + + + + [Mageia-dev] About panotools patent problem (and other problematic rpms) + + + + + + + + + +

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

+ Maarten Vanraes + maarten.vanraes at gmail.com +
+ Sat Feb 19 15:41:51 CET 2011 +

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

+ +
+More information about the Mageia-dev +mailing list
+ -- cgit v1.2.1