A number of eclasses uses the following syntax: has "${EAPI:-0}" 0 1 2 && ! use prefix && EPREFIX= AFAIK this is the official Prefix syntax. Ciaran says it's against the Holy PMS, and he was supposed to open bugs about that. What are we going to do about it?
The fix is to use EAPI 5, which (presumably) has IUSE_IMPLICIT, or to list prefix in IUSE.
There is a long-standing disagreement between Portage and PMS, on whether flags like prefix, elibc_*, kernel_*, userland_*, amd64, x86 should be implicit or not. Prefix team follows the Portage point of view on this matter, since it is most simple for us, right now. We do not want to be inbetween Portage and PMS folk for this issue. Please fight this out without us. Also note that the Prefix team is not responsible for all "use prefix" usages in the entire gx86 tree. That said, if a change is mandated, it would require many (not just Prefix) teams to act.
(In reply to comment #1) > The fix is to use EAPI 5, which (presumably) has IUSE_IMPLICIT, or to list > prefix in IUSE. But you're aware that this is not done anymore since EAPI 3?
(In reply to comment #2) > There is a long-standing disagreement between Portage and PMS, on whether > flags like prefix, elibc_*, kernel_*, userland_*, amd64, x86 should be > implicit or not. No, there's not. The fact that Portage fails to raise an error for something doesn't mean that that thing is correct. > Prefix team follows the Portage point of view on this matter, since it is > most simple for us, right now. We do not want to be inbetween Portage and > PMS folk for this issue. Please fight this out without us. Also note that > the Prefix team is not responsible for all "use prefix" usages in the entire > gx86 tree. That said, if a change is mandated, it would require many (not > just Prefix) teams to act. This isn't a Portage issue. It's a "the Council removed IUSE_IMPLICIT from EAPI 4" issue. It's very simple: going by what the Council voted on, until you're using an EAPI that includes IUSE_IMPLICIT, 'prefix' is a regular use flag that must be listed in IUSE. (In reply to comment #3) > (In reply to comment #1) > > The fix is to use EAPI 5, which (presumably) has IUSE_IMPLICIT, or to list > > prefix in IUSE. > > But you're aware that this is not done anymore since EAPI 3? Yes, and due to the Council re-ordering EAPIs and removing the feature we proposed to allow implicit prefix, this is a policy violation. Thus, the first thing to do is to make sure no new violations are introduced. The second thing to do is to clean up the mistakes people have made so far.
(In reply to comment #4) > (In reply to comment #3) > > (In reply to comment #1) > > > The fix is to use EAPI 5, which (presumably) has IUSE_IMPLICIT, or to list > > > prefix in IUSE. > > > > But you're aware that this is not done anymore since EAPI 3? > > Yes, and due to the Council re-ordering EAPIs and removing the feature we > proposed to allow implicit prefix, this is a policy violation. Thus, the > first thing to do is to make sure no new violations are introduced. The > second thing to do is to clean up the mistakes people have made so far. So, what's the correct thing to do? Do not support any new eclass on Prefix until the tree is fully migrated to mighty EAPI 5?
The correct thing to do is to ensure that prefix is listed in IUSE where it is used for any new code, to avoid making the situation even worse, and then to go and fix existing violations. The wrong thing to do is to say "it's already broken so I'll carry on introducing more breakage".
(In reply to comment #6) > The correct thing to do is to ensure that prefix is listed in IUSE where it > is used for any new code, to avoid making the situation even worse, and then > to go and fix existing violations. The wrong thing to do is to say "it's > already broken so I'll carry on introducing more breakage". This is a constructive suggestion that gets us somewhere, but requires to at least get up to a point where we all agree what should be in IUSE, and what not. After that's been agreed by the community, we can do mass-changes to the entire tree to include whatever is necessary in IUSE. In the past some people started on this, but others reverted their changes again, because they felt otherwise.
PMS already has the rules for what has to go in IUSE. For current EAPIs, if you do any querying on prefix, then prefix has to be in IUSE. That bit isn't particularly complicated, since we're not dealing with USE_EXPAND or ARCH.
(In reply to comment #7) > (In reply to comment #6) > > The correct thing to do is to ensure that prefix is listed in IUSE where it > > is used for any new code, to avoid making the situation even worse, and then > > to go and fix existing violations. The wrong thing to do is to say "it's > > already broken so I'll carry on introducing more breakage". > > This is a constructive suggestion that gets us somewhere, but requires to at > least get up to a point where we all agree what should be in IUSE, and what > not. After that's been agreed by the community, we can do mass-changes to > the entire tree to include whatever is necessary in IUSE. In the past some > people started on this, but others reverted their changes again, because > they felt otherwise. In any case, please just remember to add the IUSE only for EAPIs 0, 1 & 2.
I believe these are the eclasses involved: % grep -l "\(use prefix\|\!prefix\|prefix?\)" *.eclass autotools-utils.eclass cmake-utils.eclass emul-linux-x86.eclass fdo-mime.eclass findlib.eclass font.eclass ghc-package.eclass gnome2-utils.eclass gnome2.eclass gtk-sharp-module.eclass haskell-cabal.eclass java-vm-2.eclass mono.eclass mysql-v2.eclass mysql.eclass nsplugins.eclass perl-module.eclass qt4-build.eclass qt4-r2.eclass qt4.eclass ruby-fakegem.eclass ruby-ng-gnome2.eclass ruby-ng.eclass sgml-catalog.eclass systemd.eclass toolchain-funcs.eclass vim-doc.eclass vim-plugin.eclass vim-spell.eclass vim.eclass virtualx.eclass virtuoso.eclass
(In reply to comment #9) > In any case, please just remember to add the IUSE only for EAPIs 0, 1 & 2. Some eclasses use DEPEND=" ... !prefix? ( ... ) " deps, and other use prefix logic, so it depends on the construct being used. (In reply to comment #1) > The fix is to use EAPI 5, which (presumably) has IUSE_IMPLICIT, or to list > prefix in IUSE. Assuming it is very likely to be in EAPI 5, where exactly would that var be set? I could imagine it should be stuck in base profile with value 'prefix'. Question is how that can be done, since upgrading base to EAPI5 isn't really an option. Or are we going to allow just setting this variable, because it doesn't (or isn't supposed to) do anything on EAPIs that don't know it?
(In reply to comment #11) > Assuming it is very likely to be in EAPI 5, where exactly would that var be > set? I could imagine it should be stuck in base profile with value > 'prefix'. Question is how that can be done, since upgrading base to EAPI5 > isn't really an option. Or are we going to allow just setting this > variable, because it doesn't (or isn't supposed to) do anything on EAPIs > that don't know it? It's been worded such that we can add it to the base profiles.
Prefix EAPI=5 and higher nowadays
