Summary: | Portage should treat "${flag}? ( )" and "|| ( )" in unexpanded dependencies as error | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Arfrever Frehtes Taifersar Arahesis (RETIRED) <arfrever> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | pms |
Priority: | Normal | Keywords: | InVCS |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=636596 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 358927 | ||
Attachments: | portage-detect_invalid_dependencies.patch |
Description
Arfrever Frehtes Taifersar Arahesis (RETIRED)
![]() I guess you mean "A? ( )". This is not invalid. This case has to be dealt with for deps like: "a? ( b? ( B ) c? ( C ) )", where b and c are disabled. (In reply to comment #1) > I guess you mean "A? ( )". This is not invalid. This case has to be dealt with > for deps like: "a? ( b? ( B ) c? ( C ) )", where b and c are disabled. But when value literally specified in unexpanded DEPEND/RDEPEND/PDEPEND contains "${flag}? ( )", then why would it have to be valid? "|| ( )" also should be treated as error. Created attachment 276377 [details, diff]
portage-detect_invalid_dependencies.patch
This patch seems to work.
Thanks, this is in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1faa9bddc2859c73ce8984b43eca816c30bdb5f1 This is fixed in 2.1.10.1 and 2.2.0_alpha39. Tests are here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=a7f6576ff0b68e69a4c76402d6168ede39a69e5b *** Bug 628466 has been marked as a duplicate of this bug. *** The new behaviour contradicts PMS: https://projects.gentoo.org/pms/6/pms.html#x1-810008.2.3 However: The change in Portage was made in 2011, which means that ebuilds cannot rely on any definite behaviour with respect to empty dependency groups. Presumably this also implies that virtually all ebuild repositories will be compliant with Portage and won't use such empty groups. (Also, the spec for empty any-of and exactly-one-of groups is not what one would expect: Nullary OR and nullary XOR operation should evaluate to false, while PMS says they should evaluate to true.) So, what do you think about: - Retroactively change PMS to ban empty dependency groups, in all specification style variables. - Make Portage behaviour consistent for all variables. AFAICS, it does not allow empty groups in DEPEND and LICENSE, but allows them in REQUIRED_USE. (In reply to Zac Medico from comment #5) > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1faa9bddc2859c73ce8984b43eca816c30bdb5f1 Updated URL, for reference: https://gitweb.gentoo.org/proj/portage.git/commit/?id=1faa9bddc2859c73ce8984b43eca816c30bdb5f1 Proposed patch: https://archives.gentoo.org/gentoo-pms/message/ace2912fbbc582a08067c02ce400fedb I intend to submit this to the council agenda in September for approval. (In reply to Ulrich Müller from comment #10) > I intend to submit this to the council agenda in September for approval. Submitted and retracted again, because it appears to be controversial. Portage team, please revert commit 1faa9bddc2859c73ce8984b43eca816c30bdb5f1. Updated version approved in today's Council meeting: <dilfridge> 1) PMS changes as detailed in https://archives.gentoo.org/gentoo-pms/message/a612bdc64f7aa3e556b129a67493da1b <dilfridge> 2) note that PMS team comes up with a proposal for the next EAPI to define a behavior that seems correct in terms of resolver and our uses * dilfridge yes * K_F yes * slyfox abstains * ulm yes * mgorny yes * WilliamH yes <dilfridge> ok that's 5 yes, 1 abstention, 1 absent, motion passed The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=693019a78e99a0329b0609c01b0bad3e4b037027 commit 693019a78e99a0329b0609c01b0bad3e4b037027 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2017-10-02 16:52:41 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2017-10-08 19:11:24 +0000 Ban empty groups in dependency specifications. The specification for empty groups was originally added to match historical Portage behaviour. However, Portage was changed in 2011 to treat empty dependency groups as an error, therefore ebuilds cannot rely on any definite behaviour. Consequently, empty groups are not used by any ebuild or eclass in the Gentoo repository. Note that the explicit handling for empty groups is still retained for the case of implicit empty groups resulting from collapsing USE conditionals in any-of groups et al. This is a retroactive change for all EAPIs. Bug: https://bugs.gentoo.org/370565 dependencies.tex | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-)} The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/pms.git/commit/?id=04e3e077a99e337cb9b9f0d6e710037ba488b6bb commit 04e3e077a99e337cb9b9f0d6e710037ba488b6bb Author: Ulrich Müller <ulm@kph.uni-mainz.de> AuthorDate: 2017-10-10 10:19:31 +0000 Commit: Ulrich Müller <ulm@kph.uni-mainz.de> CommitDate: 2017-10-10 10:28:30 +0000 Appendix: Document retroactive ban of empty dependency groups. Bug: https://bugs.gentoo.org/370565 appendices.tex | 6 ++++++ dependencies.tex | 1 + 2 files changed, 7 insertions(+)} |