Bugzilla Bug 122827

dev-util/tla-1.3.4:

in DEPEND:
!ppc-macos? ( sys-apps/util-linux )

portage accepts this and only pulls in the sys-apps/util-linux dependency when
not on ppc-macos, repoman on the other hand:

% repoman scan

Setting paths:
PORTDIR = "/home/gentoo/gentoo-x86"
PORTDIR_OVERLAY = ""

RepoMan scours the neighborhood...
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name
/usr/lib/portage/bin/ebuild.sh: line 288: shopt: extdebug: invalid shell option
name

  DEPEND.badindev                2
   dev-util/tla/tla-1.3.3-r1.ebuild: ~ppc-macos(default-darwin/macos/10.4)
['sys-apps/util-linux']
   dev-util/tla/tla-1.3.4.ebuild: ~ppc-macos(default-darwin/macos/10.4)
['sys-apps/util-linux']
  RDEPEND.badindev               2
   dev-util/tla/tla-1.3.3-r1.ebuild: ~ppc-macos(default-darwin/macos/10.4)
['sys-apps/util-linux']
   dev-util/tla/tla-1.3.4.ebuild: ~ppc-macos(default-darwin/macos/10.4)
['sys-apps/util-linux']
  digest.assumed                 4
   digest-tla-1.2-r2::tla-1.2-4.diff.gz
   digest-tla-1.2-r2::tla-1.2.tar.gz
   digest-tla-1.3.4::tla-1.3.4.tar.gz
   digest-tla-1.3::tla-1.3.tar.gz

RepoMan sez: "You're only giving me a partial QA payment?
              I'll take it this time, but I'm not happy."


IOW I think it doesn't deal correctly with the ! infront of ppc-macos.

imo the behavior you're seeing is correct ... packages should not use !arch?()
in DEPENDs

in the case of tla, iirc, it has a lot of pointless DEPEND information ... i'd
say just drop util-linux altogether

ok, but there are more packages that have this.  Portage happily accepts it. 
I'd prefer to see repoman say it's bad to do that instead of assuming the ! is
not there and complain about a bad dependency...

After taking a peek at the dep_check, we have come to realize...that when on
ppc_macos, ARCH is set to ppc...However Repoman likes to set matchall, and puts
ARCH in "excludeall" in order to still resolve things.  Problem is the macos
keyword is ppc_macos, not ppc, so adding ARCH to excludeall doesn't work.

The scarier part is the ppc_macos project injects ppc_macos into keywords via
profile...so they need to be careful there lest they fubar their keywords in
the future ;)  We need to work out a way for them to have proper ARCH expansion
as well.  They currently have "ppc" in their USE flags which may match things
in ebuilds ( whether they are useful matches or bad matches remains to be seen
:) ).  Certainly adding "ppc" support to some things is good, because they get
the processor enhancements, but there may be some ppc on linux stuff that is
triggered as well, that would cause failures.  Anyway, we need this fixed :)

Yep. It's the ARCH="ppc" that springs the check. The warning is in fact valid;
portage will allow a user to USE="-ppc-macos" and have it disabled.

I believe the conclusion of this was to change ARCH on ppc-macos to ppc-macos. 
Is there any reason this isn't remotely feasable?

(In reply to comment #5)
> I believe the conclusion of this was to change ARCH on ppc-macos to ppc-macos. 
> Is there any reason this isn't remotely feasable?
> 

Its feasible, but seems far from ideal. Firstly, its a lie, the ARCH *is* ppc,
and with the introduction of {x86,ia64}-macos it will only complicate matters
further.

So if an ebuild currently uses `ppc` as a conditional thats only appropriate
for ppc/linux is not actually specific to the PPC architecture, I guess the
use_expanded kernel/libc/userland vars could be (ab)used instead.

This seems to bring us back, yet again, to the definitions of
ARCH/KEYWORD/USERLAND and glep22...

(In reply to comment #6)
> (In reply to comment #5)
> > I believe the conclusion of this was to change ARCH on ppc-macos to ppc-macos. 
> > Is there any reason this isn't remotely feasable?
> > 
> 
> Its feasible, but seems far from ideal. Firstly, its a lie, the ARCH *is* ppc,
> and with the introduction of {x86,ia64}-macos it will only complicate matters
> further.
> 
> So if an ebuild currently uses `ppc` as a conditional thats only appropriate
> for ppc/linux is not actually specific to the PPC architecture, I guess the
> use_expanded kernel/libc/userland vars could be (ab)used instead.
> 
> This seems to bring us back, yet again, to the definitions of
> ARCH/KEYWORD/USERLAND and glep22...
> 

We will need to add a new variable then, probably actually set a KEYWORD
variable in profiles, because right now we inject ARCH as your arch USE flag.
I'm kind of concerned that you currently inject ppc-macos into USE via profile,
as anyone who does -* using your profile is going to have a completely ruined
deptree.  IE, why didn't this get spotted and taken care of sooner.  Normally
portage will inject ARCH into USE and this is not over-ridable at any level. 
In regards to a solution, if we define KEYWORD and inject that instead it
should fix any issues, as long as we get it adopted by all the profiles and
arches.  We could almost use ACCEPT_KEYWORDS except there could be multiple
specified and I'm not sure how that would be handled.

I like the idea of a separate var, perhaps PROFILE_KEYWORD ?

(In reply to comment #7)
> We will need to add a new variable then, probably actually set a KEYWORD
> variable in profiles, because right now we inject ARCH as your arch USE flag.
> I'm kind of concerned that you currently inject ppc-macos into USE via profile,
> as anyone who does -* using your profile is going to have a completely ruined
> deptree.  IE, why didn't this get spotted and taken care of sooner.  Normally
> portage will inject ARCH into USE and this is not over-ridable at any level. 
> In regards to a solution, if we define KEYWORD and inject that instead it
> should fix any issues, as long as we get it adopted by all the profiles and
> arches.  We could almost use ACCEPT_KEYWORDS except there could be multiple
> specified and I'm not sure how that would be handled.

Definite no on adding ACCEPT_KEYWORDS to USE, not only due to abuse potential
but would also confuse users like hell and probably has some very tricky
implications.
So if this is truly required use a new variable, best with a sanity check to
make sure it's a valid base keyword (e.g. not a ~ keyword). Another thing to
make sure (for linux profiles) is that the final USE string only has one
occurrence of each element, haven't checked the code yet but IIRC ARCH is added
very late to USE in config, probably even after sorting and dropping dupes.

Or just create the opposite of use.mask...

In svn r5239 repoman is fixed to properly supports use.force and
package.use.force.  It was released in portage-2.1.2_rc3-r1.