Re: [gentoo-dev] EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)
On Tue, 6 Nov 2007 16:23:35 -0500 Jim Ramsay [EMAIL PROTECTED] wrote: Whether or not 'move' was the correct action in the recent compiz example, perhaps we need to consider that some times one package does actually make another obsolete. The correct thing for the PM to do is to first uninstall the obsolete package, then install the new one. snip I don't see anything in your suggestion that requires an EAPI bump to implement this. If the only thing you add to your ebuilds is the OBSOLETES variable, then a PM which doesn't recognise the enhancement will simply ignore it. In other words, OBSOLETE would not obsolete the proper negative DEPENDs (blockers) that are currently used. If you want to, say, make switching sysloggers easier by offering to uninstall metalog when the admin asks to emerge syslog-ng, then an EAPI bump would be warranted (and the proposal should be thought through a lot more thoroughly, because as of now, emerging one package and unmerging another are strictly separate actions and that should perhaps never change). Kind regards, JeR -- [EMAIL PROTECTED] mailing list
[gentoo-dev] EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)
Whether or not 'move' was the correct action in the recent compiz example, perhaps we need to consider that some times one package does actually make another obsolete. The correct thing for the PM to do is to first uninstall the obsolete package, then install the new one. Now, it has been my experience that blocking dependencies are currently used to imply this No, you have to remove cat/foo first before installing cat/bar instead situation. This is somewhat annoying for me when I want to upgrade a bunch of packages, but I have to manually uninstall a few blockers first before this is possible. This could be automated by the PM in those cases with some sort of thing like this in the cat/bar-1.0.ebuild: OBSOLETES=cat/foo Of course this would be a regular package atom (or list thereof), so it could be tied to specific versions of cat/foo. I suppose this could be seen as a special case of blocking deps which would automate a specific cat/bar is to be preferred over cat/foo However, I'm not exactly sure what you would do if you have pkg1 which depends on cat/foo and pkg2 which depends on cat/bar... -- Jim Ramsay Gentoo Developer (rox/fluxbox/gkrellm) signature.asc Description: PGP signature