Created attachment 347420 [details] Converted ebuild As the topic says, needed for emul-linux-x86-soundlibs. Attaching a converted ebuild. The ebuild works the same. Default DOCS install installs the same files as were explicitly listed.
+ amd64? ( abi_x86_32? ( + app-emulation/emul-linux-x86-baselibs[development] + ) ) hmmm, no :) - dodoc AUTHORS TODO README please define DOCS
(In reply to comment #1) > + amd64? ( abi_x86_32? ( > + app-emulation/emul-linux-x86-baselibs[development] > + ) ) > > > > hmmm, no :) That one is necessary for ncurses.
(In reply to comment #2) > (In reply to comment #1) > > + amd64? ( abi_x86_32? ( > > + app-emulation/emul-linux-x86-baselibs[development] > > + ) ) > > > > > > > > hmmm, no :) > > That one is necessary for ncurses. well, then ncurses should be converted; doing like that is simply a complete negation of all the multilib eclasses work and will make introducing new multilib arches a pain
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > + amd64? ( abi_x86_32? ( > > > + app-emulation/emul-linux-x86-baselibs[development] > > > + ) ) > > > > > > > > > > > > hmmm, no :) > > > > That one is necessary for ncurses. > > well, then ncurses should be converted; doing like that is simply a complete > negation of all the multilib eclasses work and will make introducing new > multilib arches a pain Well, it's more like an interim solution to not have to mask all conversions until every single package is converted. Especially that getting an agreement over converting baselibs is going to be worst PITA this year.
The conversion is happening in order that leaves baselibs last. Futhermore converting baselibs will be the most hardest and slowest part of the conversion.
(In reply to comment #4) (In reply to comment #5) yes, but since baselibs have to be converted someday and the "interim solution" does not scale, it makes more sense to convert them first since they're the leaves of the deptree. if it takes times, then those packages that depend on them will have to wait. IIUC the only PITA is the EAPI5 requirement, which could be lifted by setting MULTILIB_USEDEP to an invalid value (or maybe even '$(die)') for EAPI<5. I'll want to add multilib support for amd64-fbsd someday, will you remember in 6 months or 1 year what needs to be checked ? what masks have to be added ? that interim solution really sounds like a lazy hack that might get spread all over if there is no need for fixing it.
(In reply to comment #6) > (In reply to comment #4) > (In reply to comment #5) > > yes, but since baselibs have to be converted someday and the "interim > solution" does not scale, it makes more sense to convert them first since > they're the leaves of the deptree. > if it takes times, then those packages that depend on them will have to wait. > > IIUC the only PITA is the EAPI5 requirement, which could be lifted by > setting MULTILIB_USEDEP to an invalid value (or maybe even '$(die)') for > EAPI<5. The EAPI<5 problem goes other way around. You can't MULTILIB_USEDEP *on* non-EAPI 5 packages, or you'll get semi-random results...
(In reply to comment #7) I don't get this. A useflag has been the same thing since before EAPI even existed.
(In reply to comment #8) > (In reply to comment #7) > > I don't get this. A useflag has been the same thing since before EAPI even > existed. Well, it's magic implicit USE flags which give automagic values to USE_EXPAND for no good reason in EAPI<5. If A deps on B[abi_x86_32], B-1 does not have IUSE=abi_x86_32 and does use EAPI<5, the value of abi_x86_32 is assumed to always match the global flag state. You add ABI_X86=32 to make.conf, dep is satisfied though you didn't emerge anything new. You remove it, dep is not satisfied anymore though nothing in vdb changed. However stupid it may look like, this is exactly what Paludis does.
(In reply to comment #9) is there anything like that in pms ? this behavior is simply broken
(In reply to comment #10) > (In reply to comment #9) > > is there anything like that in pms ? this behavior is simply broken Yes. As far as I understand, it's based on some ancient portage behavior but Ciaran refuses to fix the spec. See bug 366555.
(In reply to comment #11) I've not read everything but I don't see how this is related: ABI_X86 is in USE_EXPAND, declared in IUSE and has nothing to do with implicit IUSE
(In reply to comment #12) > (In reply to comment #11) > > I've not read everything but I don't see how this is related: ABI_X86 is in > USE_EXPAND, declared in IUSE and has nothing to do with implicit IUSE Eh, that PMS thing is crazy to read. Now that I think about it, it could be possibly achieved using versioned deps, e.g.: >=media-libs/foo-1.2.3-r1[abi_x86_32] assuming that *all* versions from -r1 onwards use multilib-build.eclass. However, the version can't list a single non-multilib EAPI<5 package since that package will have abi_x86_32 set even if it doesn't support it. In other words: media-libs/foo[abi_x86_32] would satisfied by any EAPI<5 'foo' merged after setting ABI_X86=32 globally. Even by those who don't have a clue about multilib. So, it can work. We just need to be very careful and precise. I was probably wrong, now that I think about it. The major issue with python-r1 must've been that some ebuilds didn't support all Python versions. In the current form of multilib, all multilib flags land in each ebuild so that one is easier. Should I proceed with lowering EAPI requirements? And how low should it go?
(In reply to comment #13) > (In reply to comment #12) > > (In reply to comment #11) > > > > I've not read everything but I don't see how this is related: ABI_X86 is in > > USE_EXPAND, declared in IUSE and has nothing to do with implicit IUSE > > Eh, that PMS thing is crazy to read. Now that I think about it, it could be > possibly achieved using versioned deps, e.g.: > > >=media-libs/foo-1.2.3-r1[abi_x86_32] > > assuming that *all* versions from -r1 onwards use multilib-build.eclass. > However, the version can't list a single non-multilib EAPI<5 package since > that package will have abi_x86_32 set even if it doesn't support it. that is one solution > In other words: > > media-libs/foo[abi_x86_32] > > would satisfied by any EAPI<5 'foo' merged after setting ABI_X86=32 > globally. Even by those who don't have a clue about multilib. why? abi_x86_32 won't be in IUSE thus that dep will be an error. media-libs/foo[abi_x86_32(-)] which is what you currently get with MULTILIB_USEDEP will not be an error but any ebuild not based on multilib-build will be considered as not satisfying the dep. I always understood this was why you wrote MULTILIB_USEDEP that way. [...] > Should I proceed with lowering EAPI requirements? And how low should it go? I'd say the lowest possible; on top of my head, multilib-build or multibuild could have EAPI 0 if MULTILIB_USEDEP was banned on EAPI<5.
(In reply to comment #14) > (In reply to comment #13) > > In other words: > > > > media-libs/foo[abi_x86_32] > > > > would satisfied by any EAPI<5 'foo' merged after setting ABI_X86=32 > > globally. Even by those who don't have a clue about multilib. > > why? abi_x86_32 won't be in IUSE thus that dep will be an error. Actually, it is in IUSE_EFFECTIVE or whatever the theoretical variable were. All USE_EXPAND flags are. This sucks real much but Ciaran won't allow changing it -- he just snapshotted some very stupid moment in portage's behavior in that PMS thing and refuses to change it to reflect reality, and we refuse to modify portage to behave that stupid.
(In reply to comment #15) I fail to see what you want to change.
(In reply to comment #16) > (In reply to comment #15) > > I fail to see what you want to change. I mean that every EAPI<5 package out there built since ABI_X86 became an USE_EXPAND has some state of abi_x86_* flags recorded, and it is perfectly valid to depend on that state, per the words of PMS.
(In reply to comment #17) there's no problem here I think: IUSE_REFERENCEABLE is a variable calculated from IUSE and a variety of other sources described below. It is purely a conceptual variable; it is not exported to the ebuild environment. Values in IUSE_REFERENCEABLE may legally be used in queries from other packages about an ebuild’s state (for example, for use dependencies). IUSE_EFFECTIVE is another conceptual, unexported variable. Values in IUSE_ EFFECTIVE are those which an ebuild may legally use in queries about itself (for example, for the use function, and for use in dependency specification conditional blocks). For EAPIs listed in table 5.2 as not supporting profile defined IUSE injection, IUSE_REFERENCEABLE is equal to the calculated IUSE value. For EAPIs where profile defined IUSE injection is supported, IUSE_REFERENCEABLE is equal to IUSE_EFFECTIVE. -> it is broken to have a non multilib-build ebuild satisfy a foo[abi_x86_32(-)] dep.
also: In a 4-style use dependency, the flag name may immediately be followed by a default specified by either (+) or (-). The former indicates that, when applying the use dependency to a package that does not have the flag in question in IUSE_REFERENCEABLE, the package manager shall behave as if the flag were present and enabled; the latter, present and disabled. Unless a 4-style default is specified, it is an error for a use dependency to be applied to an ebuild which does not have the flag in question in IUSE_REFERENCEABLE.
(In reply to comment #19) > also: > > In a 4-style use dependency, the flag name may immediately be followed by a > default specified by either (+) or (-). The former indicates that, when > applying the use dependency to a package that does not have the flag in > question in IUSE_REFERENCEABLE, the package manager shall behave as if the > flag were present and enabled; the latter, present and disabled. > > Unless a 4-style default is specified, it is an error for a use dependency > to be applied to an ebuild which does not have the flag in question in > IUSE_REFERENCEABLE. Hmm, that permits us to use EAPI=4, correct?
(In reply to comment #20) > Hmm, that permits us to use EAPI=4, correct? should be, yes, but that wont be enough for baselibs I fear
(In reply to comment #21) > (In reply to comment #20) > > Hmm, that permits us to use EAPI=4, correct? > > should be, yes, but that wont be enough for baselibs I fear Ok, EAPI=4 support added. For older EAPIs we'd need someone doing a review of the eclass; we'd also want to make MULTILIB_USEDEP something like 'PLEASE-USE-EAPI-5'.
(In reply to comment #22) > (In reply to comment #21) > > (In reply to comment #20) > > > Hmm, that permits us to use EAPI=4, correct? > > > > should be, yes, but that wont be enough for baselibs I fear > > Ok, EAPI=4 support added. For older EAPIs we'd need someone doing a review > of the eclass; we'd also want to make MULTILIB_USEDEP something like > 'PLEASE-USE-EAPI-5'. Then, I guess this will need to be converted anyway before getting all baselibs because it's not possible to make multilib eclasses work with eapi0 (that is the eapi that I think some packages required, no?)
Anyway, how many packages from baselibs will need eapi0? Probably a lot of included packages (like gamin or pulseaudio) could be migrated already and baselibs set be reduced a lot (yes, this would also be a temporally solution as a smaller emul baselibs set would still be needed until affected packages can be moved to newer eapi or emul eclasses be used with eapi0). Also, I doubt if we should keep eapi0 usage forever in that packages... but I guess it's too hard to migrate them :|
For example, do you know the reason for not allowing more eapis in toolchain-binutils.eclass? It would "only" require to set new phases (like src_prepare, configure...), that is what we already did in gnome2.eclass long time ago, or are there some hidden magic in newer eclasses that would break the packages?
I don't think many. I think the current @system set depends on EAPI=4 already, and the most horrible packages like glibc & gcc are unlikely to use multilib eclasses since they handle multilib their own way. We don't need to count them since they are not in emul-linux. That leaves us packages such as zlib, bzip2... if we can know which EAPI is fine for them, we should be good. Bug #457134 is open since Feb 2013, so vapier is likely to respond sometime near Feb 2014.
(In reply to comment #26) > That leaves us packages such as zlib, bzip2... if we can know which EAPI is > fine for them, we should be good. Bug #457134 is open since Feb 2013, so > vapier is likely to respond sometime near Feb 2014. you should push for it more actively; this is precisely why I'm against depending on emul packages: a "temporary workaround" might very well stay there for years.
i went with a multilib-minimal migration in the end; ncurses / readline isnt needed in fact, only for binaries so we dont care having it MULTILIB_USEDEP.
One note: multilib_is_native_abi().
(In reply to Michał Górny from comment #29) > One note: multilib_is_native_abi(). did you add it finally ? it isnt much more complex to do ABI != DEFAULT_ABI
(In reply to Alexis Ballier from comment #30) > (In reply to Michał Górny from comment #29) > > One note: multilib_is_native_abi(). > > did you add it finally ? it isnt much more complex to do ABI != DEFAULT_ABI Yes, I did. The advantage of that function is that if starts behaving wrong, we don't need to fix it in all places.
