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.
