On Tue, Dec 11, 2012 at 03:29:11AM +0100, Johnny A. Solbu wrote: > Another thing is that some pakcages listed in task-obsolete clearly doesn't > belong there. > I took a quick glance on the spec file for task-obsolete. and I notice that > some of the packages listed should be listed in the packages that replace > them. > One example is «policykit» where the comment says is replaced by «polkit». > I've read in other mails on this list that in situations where a package is > replaced by a package with another name, the new package should obsolete the > old one. > I’m not so sure about that. The problem with obsoletes is that once you put it in the spec you can’t remove it until the last supported release that included the old package is eol’d (and assuming one doesn’t upgrade from a very old release straight to the last one).
The consequence of this is that over time spec files tend to carry a lot of history which kind of gets in the way. Having a task-obsolete is a nice way to tidy specfiles and have all that garbage in only one can. It can also help automating cleanup, because there’s only one spec file to update once a distribution gets eol’d. With obsoletes in each spec file we tend to forget these obsoletes are obsolete themselves and carry useless instructions. Of course it means more work first because you have 2 packages to modify and submit, but in the long run I think it can help keeping the specs clear, and I hope the intent of this package was this. I may be wrong, but if you agree with that, a nice addition would be to add a convention, no wait, a policy to tell how to add a package to task-obsolete like adding a comment before with a timestamp or a distribution release number so that it can effectively be cleaned. Regards, -- Rémy CLOUARD () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments