Summary: | repoman reports different errors depending on current profile | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Sergei Trofimovich (RETIRED) <slyfox> |
Component: | Repoman | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | mgorny, wlt-ml |
Priority: | Normal | Keywords: | NeedPatch |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Sergei Trofimovich (RETIRED)
2017-02-25 12:18:20 UTC
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. |