summaryrefslogtreecommitdiffstats
path: root/zarb-ml/mageia-dev/20110220/002691.html
blob: cc24ccf1236b02f3db43351a956a1e6cf72ed175 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
 <HEAD>
   <TITLE> [Mageia-dev] About panotools patent problem (and other problematic rpms)
   </TITLE>
   <LINK REL="Index" HREF="index.html" >
   <LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20About%20panotools%20patent%20problem%20%28and%20other%0A%20problematic%20rpms%29&In-Reply-To=%3C4D6161E4.9030700%40iki.fi%3E">
   <META NAME="robots" CONTENT="index,nofollow">
   <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
   <LINK REL="Previous"  HREF="002690.html">
   <LINK REL="Next"  HREF="002692.html">
 </HEAD>
 <BODY BGCOLOR="#ffffff">
   <H1>[Mageia-dev] About panotools patent problem (and other problematic rpms)</H1>
    <B>Thomas Backlund</B> 
    <A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20About%20panotools%20patent%20problem%20%28and%20other%0A%20problematic%20rpms%29&In-Reply-To=%3C4D6161E4.9030700%40iki.fi%3E"
       TITLE="[Mageia-dev] About panotools patent problem (and other problematic rpms)">tmb at iki.fi
       </A><BR>
    <I>Sun Feb 20 19:48:04 CET 2011</I>
    <P><UL>
        <LI>Previous message: <A HREF="002690.html">[Mageia-dev] time to switch from raw partitions to lvm?
</A></li>
        <LI>Next message: <A HREF="002692.html">[Mageia-dev] About panotools patent problem (and other	problematic rpms)
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#2691">[ date ]</a>
              <a href="thread.html#2691">[ thread ]</a>
              <a href="subject.html#2691">[ subject ]</a>
              <a href="author.html#2691">[ author ]</a>
         </LI>
       </UL>
    <HR>  
<!--beginarticle-->
<PRE>Michael Scherer skrev 18.2.2011 15:42:
&gt;<i> Le vendredi 18 f&#233;vrier 2011 &#224; 12:47 +0000, James Kerr a &#233;crit :
</I>&gt;<i>
</I>&gt;&gt;<i> If there are two packages, one in core and another in tainted, then
</I>&gt;&gt;<i> doesn't urpmi need a way to recognise that the tainted package is newer
</I>&gt;&gt;<i> than (an update to) the corresponding core package? I believe that this
</I>&gt;&gt;<i> is achieved in Mandriva, because plf is greater than mdv.
</I>&gt;<i>
</I>&gt;<i> That's abusing release tag and it work by pure chance ( ie, had the plf
</I>&gt;<i> decided to  be called the guillomovitch liberation front, it would not
</I>&gt;<i> have worked ). And this is quite inflexible, since people will always
</I>&gt;<i> have plf packages, leading to users adding some rpm in skip.list with a
</I>&gt;<i> regexp.
</I>&gt;<i>
</I>
It is an abuse yes,
but the great thing about it is we _know_ it works...
so no surprises...

(if it aint broken...)

&gt;<i> This doesn't make much sense to treat tainted rpm as update to core,
</I>&gt;<i> this is not the same notion. But we cannot express this in urpmi for the
</I>&gt;<i> moment, as this would requires some way to say &quot;if you need to install
</I>&gt;<i> something, prefer this source rather than this one&quot;.
</I>&gt;<i>
</I>&gt;<i> We can imagine a priority system, or we can simply say that if there is
</I>&gt;<i> the same rpm on 2 media, we ask to the user ( except this would requires
</I>&gt;<i> IMHO a better system than the current path based one to see what is in a
</I>&gt;<i> rpm, but that's a rather long proposal to make ).
</I>&gt;<i>
</I>
Well, the old simple logic works...

lets say we &quot;abuse&quot; the release tag, for example changing &quot;mga&quot; to &quot;mgt&quot;
then if the user enables &quot;tainted&quot; (meaning he/she wants the rpms) urpmi 
will automatically get the &quot;mgt&quot; ones, no questions asked...

simple, and effective.

and since the rebuild should be automatically on our bs, the versions
will stay in sync.

&gt;<i> But you are right this another set of issues to solve for dual life
</I>&gt;<i> packages.
</I>&gt;<i>
</I>
I'd say go for the setup that we know works for Mageia 1, and re-evalute 
the issue after...

--
Thomas
</PRE>


<!--endarticle-->
    <HR>
    <P><UL>
        <!--threads-->
	<LI>Previous message: <A HREF="002690.html">[Mageia-dev] time to switch from raw partitions to lvm?
</A></li>
	<LI>Next message: <A HREF="002692.html">[Mageia-dev] About panotools patent problem (and other	problematic rpms)
</A></li>
         <LI> <B>Messages sorted by:</B> 
              <a href="date.html#2691">[ date ]</a>
              <a href="thread.html#2691">[ thread ]</a>
              <a href="subject.html#2691">[ subject ]</a>
              <a href="author.html#2691">[ author ]</a>
         </LI>
       </UL>

<hr>
<a href="https://www.mageia.org/mailman/listinfo/mageia-dev">More information about the Mageia-dev
mailing list</a><br>
</body></html>