Bug 22225 - repoman fails to commit a stable package which depends on a virtual which is satisfied by a package with unstable keywords
Bug#: 22225 Product:  Portage Development Version: unspecified Platform: All
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: FIXED Assigned To: dev-portage@gentoo.org Reported By: mkennedy@gentoo.org
Component: Unclassified (old)
URL: 
Summary: repoman fails to commit a stable package which depends on a virtual which is satisfied by a package with unstable keywords
Keywords:  InCVS
Status Whiteboard: 
Opened: 2003-06-04 13:43 0000
Description:   Opened: 2003-06-04 13:43 0000
hi carpaski,

took me a while to track this one down...

I have ACCEPT_KEYWORDS=~x86 in my make.conf.

virutal/emacs can be satisfied by either app-editors/emacs or app-editors/emacs-cvs.

i have an ebuild "foo" (actually every ebuild in app-emacs is affected by this
bug), which DEPENDS="virutal/emacs". 

app-editors/emacs-cvs is all masked (with ~ keywords)
app-editors/emacs isn't

I have app-editors/emacs-cvs emerged, but no app-editors/emacs.

now for package foo, i "repoman commit" and it fails with a bad depend on
"virtual/emacs".

After a lot of futzing around, I change app-editors/emacs-cvs to stable
keywords, and it worked.

------------------

So here i think is the guts of the problem: we cannot have a virtual in a
package with stable keywords when one or more of the ebuilds which satisfy the
virtual has unstable keywords.

Just a note -- it might be something recent in portage which caused this to
break, because it used to work (i added app-emacs/* originally and it worked at
that time).

In the meantime, I'm changing app-editors/emacs-cvs to stable keywords as a work
around.

Matt

------- Comment #1 From Marius Mauch (RETIRED) 2003-10-09 12:31:12 0000 -------
re-assigning to puggy as he is the main repoman guy now. 

------- Comment #2 From Masatomo Nakano (RETIRED) 2004-01-01 20:59:56 0000 -------
fixed in cvs

------- Comment #3 From Marius Mauch (RETIRED) 2004-02-08 17:55:13 0000 -------
supposed to be fixed in 2.0.50 which is stable now. If this bug is not fixed
please reopen.