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

[Colin Guthrie]

'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/