| Summary: | app-emulation/emul-linux-x86-soundlibs: make use of sci-libs/fftw[abi_x86_32] | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Christoph Junghans (RETIRED) <junghans> |
| Component: | [OLD] Unspecified | Assignee: | AMD64 Project <amd64> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ansla80, mgorny, smaarster |
| Priority: | Normal | Keywords: | PATCH |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | change for emul-linux-x86-soundlibs-20121202.ebuild | ||
Have you talked with mgorny? I think he is doing a lot of work related with moving to real multilib and, then, a lot more changed could be needed in the near future for this ebuild :| Ah, you migrated it already? But nice work, to be honest. Great idea with the ABI-conditional blocker, that's something that didn't come into my mind. It's going to make the migration a lot less painful. @Pacho, his ebuild uses the new eclass already, so it's fine as-is. However, I'm not sure if we shouldn't wait a bit and migrate more packages before updating the emul-linux package. Otherwise, we may end up with -r33 ;P. Other doubt is that we probably should use exact-versioned dep. As the reverse dependencies are still binary, we need to have the same SONAME as it was in the emul-linux package. I would also try to run all 6 configure variants in parallel but that's just my craziness ;). (In reply to comment #3) > @Pacho, his ebuild uses the new eclass already, so it's fine as-is. However, > I'm not sure if we shouldn't wait a bit and migrate more packages before > updating the emul-linux package. Otherwise, we may end up with -r33 ;P. That was the idea, wait more and do most of the changes together > > Other doubt is that we probably should use exact-versioned dep. As the > reverse dependencies are still binary, we need to have the same SONAME as it > was in the emul-linux package. > I think it won't be needed, simply remember to migrate all slots included in emul sets. I even doubt if this new emul packages only pulling deps will ever go to stable, as once packages support multilib themselves, rdeps should be migrated to directly depend on exact libs their need and, then, finally all this emul packages should be removed after migration period > I would also try to run all 6 configure variants in parallel but that's just > my craziness ;). (In reply to comment #4) > (In reply to comment #3) > > @Pacho, his ebuild uses the new eclass already, so it's fine as-is. However, > > I'm not sure if we shouldn't wait a bit and migrate more packages before > > updating the emul-linux package. Otherwise, we may end up with -r33 ;P. > > That was the idea, wait more and do most of the changes together Yes, with the conditional blockers like one done in fftw, it shouldn't hurt non-multilib use. > > Other doubt is that we probably should use exact-versioned dep. As the > > reverse dependencies are still binary, we need to have the same SONAME as it > > was in the emul-linux package. > > > > I think it won't be needed, simply remember to migrate all slots included in > emul sets. > > I even doubt if this new emul packages only pulling deps will ever go to > stable, as once packages support multilib themselves, rdeps should be > migrated to directly depend on exact libs their need and, then, finally all > this emul packages should be removed after migration period Hmm, sounds right. We should probably stable-mask the abi_x86_32 flag on amd64 multilib profile, so that we can stabilize the new packages before stabilizing the emul-linux-x86 replacement. fftw has nearly no deps, which is why it was easy to convert, but in general I think it would be better to start with converting emul-linux-x86-baselibs. I have no problem with having 33 revs of emul-linux-x86-soundlibs, at least we see what breaks along the way, but I am also happy with going the other way, too. I guess, it would be useful to create a tracker and make individual bugs for every package, which needs to be converted to multilib-build. (In reply to comment #6) > fftw has nearly no deps, which is why it was easy to convert, but in general > I think it would be better to start with converting emul-linux-x86-baselibs. > > I have no problem with having 33 revs of emul-linux-x86-soundlibs, at least > we see what breaks along the way, but I am also happy with going the other > way, too. > > I guess, it would be useful to create a tracker and make individual bugs for > every package, which needs to be converted to multilib-build. I agree with the tracker, do you have some script to report the bugs? The list of packages in soundlibs is: http://www.gentoo.org/proj/en/base/amd64/emul/emul-linux-x86-20121202.xml#doc_chap14 (In reply to comment #7) > I agree with the tracker, do you have some script to report the bugs? The > list of packages in soundlibs is: > http://www.gentoo.org/proj/en/base/amd64/emul/emul-linux-x86-20121202. > xml#doc_chap14 No, but I can write one, I wanted to look into pybugz anyhow at some point. I am just not sure if emul-linux-x86-soundlibs would be the right package to start with or if emul-linux-x86-baselibs would be better. Was done by aballier: *emul-linux-x86-soundlibs-20130224-r3 (27 Jun 2013) 27 Jun 2013; Alexis Ballier <aballier@gentoo.org> -emul-linux-x86-soundlibs-20130224-r2.ebuild, +emul-linux-x86-soundlibs-20130224-r3.ebuild, files/remove-native: remove fftw and the ladspa plugins with abi_x86_32 Feel free to go ahead and modify emul set ebuilds in the same way for new libs |
Created attachment 337734 [details, diff] change for emul-linux-x86-soundlibs-20121202.ebuild fftw-3.3.3-r1 has real multilib capability, so let use it.