https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=66b9feb7fb6fd56594f9dab7f9f5e85b8fe3cf20 triggered a few repoman failures in :haskell and ::java overlays namely: https://travis-ci.org/gentoo-haskell/gentoo-haskell/builds/205244507 IUSE.missing [fatal] dev-lang/ghc/ghc-7.8.4.ebuild: SRC_URI: USE flag 'alpha' referenced in conditional 'alpha?' is not in IUSE https://travis-ci.org/Obsidian-StudiosInc/os-xtoo/builds/204736837 IUSE.missing [fatal] dev-java/oracle-jdk-bin/oracle-jdk-bin-9_pre157.ebuild: SRC_URI: USE flag 'amd64' referenced in conditional 'amd64?' is not in IUSE The unusual setup here is base (arch-less) profile: $ ln -s /usr/portage/profiles/base/ /etc/portage/make.profile If the profile is default/linux/amd64/13.0 then no errors are reported. Ideally repoman should not depend on current profile and load arch list from every checked profile. Maybe it already does and ::gentoo is broken?
This is a design issue with implicit flags. They mean that an ebuild can be valid or not depending on the profile in use. So yes, it might be reasonable to recheck the ebuild with all defined profiles. However, the necessary bits are kept in common directories that are used by all Gentoo profiles, i.e. we keep this working by policy. If you are using a broken profile, then you really shouldn't expect things to work, and unless we're planning on making repoman work without any profile, I don't see much of a point in putting an effort to make it work with broken profile. Plus, I'm a little worried about adding more work to repoman (= making it even slower) to account for what basically is a possibility of the ebuild being broken by a broken profile. If at all, I guess it'd be better to actually check profiles for being broken... If you really want to play with it, I guess we can look at a patch. But I don't think there's really a reason for Portage team to put it on TODO.
(In reply to Sergei Trofimovich from comment #0) > Ideally repoman should not depend on current profile and load > arch list from every checked profile. It's got nothing to do with the arch list. Since EAPI 5, it's governed by the USE_EXPAND_IMPLICIT and USE_EXPAND_VALUES_ARCH variables which are currently defined in profiles/arch/base/make.defaults. If you want to change the behavior then you'll have to change PMS.
(In reply to Sergei Trofimovich from comment #0) > The unusual setup here is base (arch-less) profile: > $ ln -s /usr/portage/profiles/base/ /etc/portage/make.profile There's the problem. You need a profile that also inherits arch/base.
(In reply to Zac Medico from comment #3) > (In reply to Sergei Trofimovich from comment #0) > > The unusual setup here is base (arch-less) profile: > > $ ln -s /usr/portage/profiles/base/ /etc/portage/make.profile > > There's the problem. You need a profile that also inherits arch/base. Right. I've worked around it with: https://github.com/mrueg/repoman-travis/commit/668ff60c34b81ab3c246af86e5de1d450f1751c5 It felt wrong to have to rely on arch-specific profile for a thing that is supposed to verify ebuild validity on all archies/profiles.
(In reply to Sergei Trofimovich from comment #4 > It felt wrong to have to rely on arch-specific profile for a thing > that is supposed to verify ebuild validity on all archies/profiles. Any valid profile will work, and profiles/base just isn't valid. If you want, maybe you can adjust the base profile to suite your needs. I don't see any problems with portage or PMS. Can we close this bug?
(In reply to Zac Medico from comment #5) > Can we close this bug? Sure.
