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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE> [Mageia-dev] Package drop request: ruby-ParseTree
</TITLE>
<LINK REL="Index" HREF="index.html" >
<LINK REL="made" HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Package%20drop%20request%3A%20ruby-ParseTree&In-Reply-To=%3C50C70DA7.9050304%40colin.guthr.ie%3E">
<META NAME="robots" CONTENT="index,nofollow">
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">
<LINK REL="Previous" HREF="020735.html">
<LINK REL="Next" HREF="020733.html">
</HEAD>
<BODY BGCOLOR="#ffffff">
<H1>[Mageia-dev] Package drop request: ruby-ParseTree</H1>
<B>Colin Guthrie</B>
<A HREF="mailto:mageia-dev%40mageia.org?Subject=Re%3A%20%5BMageia-dev%5D%20Package%20drop%20request%3A%20ruby-ParseTree&In-Reply-To=%3C50C70DA7.9050304%40colin.guthr.ie%3E"
TITLE="[Mageia-dev] Package drop request: ruby-ParseTree">mageia at colin.guthr.ie
</A><BR>
<I>Tue Dec 11 11:40:39 CET 2012</I>
<P><UL>
<LI>Previous message: <A HREF="020735.html">[Mageia-dev] Package drop request: ruby-ParseTree
</A></li>
<LI>Next message: <A HREF="020733.html">[Mageia-dev] The «task-obsolete» debate [Was: Package drop request: ruby-ParseTree]
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#20736">[ date ]</a>
<a href="thread.html#20736">[ thread ]</a>
<a href="subject.html#20736">[ subject ]</a>
<a href="author.html#20736">[ author ]</a>
</LI>
</UL>
<HR>
<!--beginarticle-->
<PRE>'Twas brillig, and Remy CLOUARD at 11/12/12 06:38 did gyre and gimble:
><i> On Mon, Dec 10, 2012 at 11:41:38PM +0000, Colin Guthrie wrote:
</I>>><i> So what if we provide this library and someone uses it as a component in
</I>>><i> some other app they write.
</I>>><i>
</I>>><i> They likely have an expectation that it will continue to be supported
</I>>><i> and that any security vulnerabilities in it are detected and fixed.
</I>>><i>
</I>>><i> If we don't have a mechanism to remove (or at least very strongly
</I>>><i> recommend to remove) package we no longer support, then we are leaving
</I>>><i> users vulnerable.
</I>>><i>
</I>>><i> The orphans system is fine, but it's certainly not as strong a mechanism
</I>>><i> as I think is needed.
</I>><i> Well, that would be very lazy from that person not to test the app and
</I>><i> release it. Actually, the ruby community has a strong focus on test
</I>><i> driven development. Since that library is broken with ruby 1.9, it won’t
</I>><i> pass the first test. So no worries here. Actually, I’m pretty sure it
</I>><i> couldn’t even stay on the machine just because it is linked against
</I>><i> libruby.so.1.8, and we provide libruby.so.1.9.
</I>><i>
</I>><i> In the ruby policy I added as a requirement a
</I>><i> Requires: ruby(abi) = version
</I>><i> I’m pleased to see this is now an automatic thing, meaning that a
</I>><i> package that’s doesn’t build won’t stand a chance to stay on people’s
</I>><i> machine.
</I>
Yes, but keep in mind that the task-obsolete thing is not just about
ruby and it also shouldn't rely on people not being lazy and releasing
something. Perhaps their app is not for public release anyway.
So sadly, we can't design mechanisms around this structure.
><i> That being said it still requires human intervention to remove it from
</I>><i> the mirrors.
</I>
I wonder if we could have a helper that runs on svn commit hook when a
package is moved to the old tree? That would avoid the task-obsolete
"abuse" but still doesn't provide a mechanism to remove from users
machines...
><i> To me this is a rather sane way to deal with the problem, because it’s
</I>><i> self-explanatory: the package can’t stay because its requirements are
</I>><i> not met. If you add it to task-obsolete, you provide no reason to the
</I>><i> user, most of the time the explanation is only a comment in
</I>><i> task-obsolete’s spec file.
</I>
This only works when it's true :) Sometimes a package is dropped because
it doesn't build with newer gcc and there is no maintainer or enough
users to merit it being fixed. Lots of things other than "requirements
not met" result in packages being dropped. And if they are dropped they
are not supported and we do not accept bug reports etc. etc. These
packages should, in theory, be removed from a users machine unless the
user takes very specific action to block this.
Personally I'd be more in favour of expanding the urpmq --not-available
system. It could just be beefed up to allow exclusions (like skip.list,
but rather a keep.list). Then a urpme --not-available could be added to
remove any no longer available packages.
This would require GUI enhancements but it might be a good compromise here.
Col
--
Colin Guthrie
colin(at)mageia.org
<A HREF="http://colin.guthr.ie/">http://colin.guthr.ie/</A>
Day Job:
Tribalogic Limited <A HREF="http://www.tribalogic.net/">http://www.tribalogic.net/</A>
Open Source:
Mageia Contributor <A HREF="http://www.mageia.org/">http://www.mageia.org/</A>
PulseAudio Hacker <A HREF="http://www.pulseaudio.org/">http://www.pulseaudio.org/</A>
Trac Hacker <A HREF="http://trac.edgewall.org/">http://trac.edgewall.org/</A>
</PRE>
<!--endarticle-->
<HR>
<P><UL>
<!--threads-->
<LI>Previous message: <A HREF="020735.html">[Mageia-dev] Package drop request: ruby-ParseTree
</A></li>
<LI>Next message: <A HREF="020733.html">[Mageia-dev] The «task-obsolete» debate [Was: Package drop request: ruby-ParseTree]
</A></li>
<LI> <B>Messages sorted by:</B>
<a href="date.html#20736">[ date ]</a>
<a href="thread.html#20736">[ thread ]</a>
<a href="subject.html#20736">[ subject ]</a>
<a href="author.html#20736">[ 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>
|
