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

[Colin Guthrie]

'Twas brillig, and nicolas vigier at 10/12/12 14:27 did gyre and gimble:
> On Mon, 10 Dec 2012, Colin Guthrie wrote:
> 
>> 'Twas brillig, and Johnny A. Solbu at 08/12/12 10:37 did gyre and gimble:
>>> On Saturday 8. December 2012 11.06, Guillaume Rousse wrote:
>>>>> Unless I misunderstand, adding it to «task-obsolete» does the same thing, with a 2 week delay on deleting.
>>>>> So the proper action would be to add it to «task-obsolete».
>>>> That's still not the proper action. 
>>>
>>> In other words, I did misunderstand.
>>>
>>>> Stop removing packages from end 
>>>> user machines just to remove them from the mirrors as a side effect of 
>>>> our package submission procedure.
>>>
>>> So what should we do?
>>> The current packaging guidelines[1] says that this is the correct action for obsolete packages, which a depcrecated package is.
>>> If this is not the desired solution, then the guidelines should change. Perhaps just clairfied as to what is an obsolete package, which belongs in task-obsolete, and what is Not an obsolete package even if it's deprecated.
>>>
>>> [1] https://wiki.mageia.org/en/Packaging_guidelines#Obsoleting_a_package
>>
>> I totally agree with Johnny here. If users want to keep unmaintained and
>> no-longer-supplied packages on their machine (obviously making a
>> concious decision to not get security updates etc. on such packages)
>> then they are welcome to add task-obsolete to their urpmi skip lists.
>>
>> I see absolutely no problem with this and I don't consider this
>> something that's done as a "side effect", rather it's a quite deliberate
>> and concious mechanism to remove no longer supported packages from a
>> users machine.
> 
> One of the problem with task-obsolete obsoleting packages is that it can
> silently uninstall packages and break something which was working,
> without warning.

I don't disagree, but by the same token if a user is advanced enough to
use such things with stuff they have installed manually, then chances
are they're advanced enough to uninstall and block task-obsolete too.
The fact that there is no-warning is certainly not ideal, but I doubt it
would be an actual real problem to many users anyway. And it's not like
they can't just find a mirror with the package they had installed and
reinstall it again anyway when they notice it breaks things. Not ideal I
agree, but all the same, not terrible either.

> Maybe instead of obsoleting packages, task-obsolete could conflict with
> those packages :

Could it obsolete *and* conflict packages and get the best of both
worlds? If that was the case it should work both from a UI level and
also from a structural (i.e. repository) level.

If that works, then we just define a simple macro at the top of the spec
and use it throughout:

%kill foo
%kill wibble

etc. which automatically adds both the conflicts and the obsoletes tags.

> Or we can stop using task-obsolete package, and instead create a file
> "unsupported" in media_info directory on the mirrors containing a list
> of unsupported packages, and used by urpmq/urpme --unsupported to
> list/remove unsupported packages.
> 
> What do you think ?

That would work too (although "urpmq --not-available" is almost the same
as that anyway really and doesn't need a specific list).

The problem still to be solved here however, is allowing packagers easy
access to the process of doing the tidying without having to rely on
someone from sysadmin manually doing some intervention.

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/