From: Steve Long <slong@rathaus.eclipse.co.uk>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007)
Date: Wed, 07 Nov 2007 14:09:50 +0000 [thread overview]
Message-ID: <fgsgo0$ues$1@ger.gmane.org> (raw)
In-Reply-To: 20071106162335.482c6e4f@vrm378-02
Jim Ramsay 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.
>
I don't think it was, for the reasons stated on the bug, and based on what
Mr Mauch has just said.
> 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.
>
You can use a script to automate that [1] so it's just a question of
pressing any key to unmerge (depending on the block; it might not actually
apply by the time you come to the blocked app.)
> 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 really like that idea. (A RECOMMENDS thing similar to debian would be nice
too.)
> 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...
>
That kinda sounds like the same issue genone was raising; since the
difference upstream is tied to a version, whereas the Gentoo package names
apply to all versions there can be no guarantee of compatibility. Maybe you
could get round this by only using versioned deps. (So a package move
script would have to ensure nothing had an unversioned dep on either
package.)
[1] http://forums.gentoo.org/viewtopic-t-546828.html
New, improved-- shiny! ;D
--
gentoo-dev@gentoo.org mailing list
next prev parent reply other threads:[~2007-11-07 14:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1IpCox-0008Sj-Sg@stork.gentoo.org>
2007-11-06 16:15 ` [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles/updates: 4Q-2007 Mark Loeser
2007-11-06 16:25 ` Doug Klima
2007-11-06 19:18 ` Petteri Räty
2007-11-06 20:03 ` Marius Mauch
2007-11-06 21:23 ` [gentoo-dev] EAPI feature suggestion: OBSOLETES (was: gentoo-x86 commit in profiles/updates: 4Q-2007) Jim Ramsay
2007-11-07 14:09 ` Steve Long [this message]
2007-11-07 18:37 ` [gentoo-dev] " Santiago M. Mola
2007-11-08 4:50 ` [gentoo-dev] " Jeroen Roovers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='fgsgo0$ues$1@ger.gmane.org' \
--to=slong@rathaus.eclipse.co.uk \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox