[Mageia-dev] Package drop request: ruby-ParseTree

Tue Dec 11 11:40:39 CET 2012

'Twas brillig, and Remy CLOUARD at 11/12/12 06:38 did gyre and gimble:
+> On Mon, Dec 10, 2012 at 11:41:38PM +0000, Colin Guthrie wrote:
+>> So what if we provide this library and someone uses it as a component in
+>> some other app they write.
+>>
+>> They likely have an expectation that it will continue to be supported
+>> and that any security vulnerabilities in it are detected and fixed.
+>>
+>> If we don't have a mechanism to remove (or at least very strongly
+>> recommend to remove) package we no longer support, then we are leaving
+>> users vulnerable.
+>>
+>> The orphans system is fine, but it's certainly not as strong a mechanism
+>> as I think is needed.
+> Well, that would be very lazy from that person not to test the app and
+> release it. Actually, the ruby community has a strong focus on test
+> driven development. Since that library is broken with ruby 1.9, it won’t
+> pass the first test. So no worries here. Actually, I’m pretty sure it
+> couldn’t even stay on the machine just because it is linked against
+> libruby.so.1.8, and we provide libruby.so.1.9.
+> 
+> In the ruby policy I added as a requirement a
+> Requires: ruby(abi) = version
+> I’m pleased to see this is now an automatic thing, meaning that a
+> package that’s doesn’t build won’t stand a chance to stay on people’s
+> machine.
+
+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.
+
+> That being said it still requires human intervention to remove it from
+> the mirrors.
+
+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...
+
+> To me this is a rather sane way to deal with the problem, because it’s
+> self-explanatory: the package can’t stay because its requirements are
+> not met. If you add it to task-obsolete, you provide no reason to the
+> user, most of the time the explanation is only a comment in
+> task-obsolete’s spec file.
+
+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
+http://colin.guthr.ie/
+
+Day Job:
+  Tribalogic Limited http://www.tribalogic.net/
+Open Source:
+  Mageia Contributor http://www.mageia.org/
+  PulseAudio Hacker http://www.pulseaudio.org/
+  Trac Hacker http://trac.edgewall.org/
+