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

Mon Dec 10 15:42:31 CET 2012

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