Re: [gentoo-dev] Multilib project newsletter #n
Dnia 2014-07-02, o godz. 07:24:09 Ulrich Mueller napisał(a): > > On Tue, 01 Jul 2014, Ian Stakenvicius wrote: > > > On 01/07/14 06:44 PM, Ciaran McCreesh wrote: > >>> || ( amd64? ( > >> > >> I thought we were trying to discourage that abomination... > > > It's still necessary, unfortunately, until such time as everything > > in the tree no longer needs/depends on the emul-* packages (see news > > item #8 for progress). Otherwise, end-users would end up with > > dependency collisions. > > Sure, the second block is needed, but the point is that foo? ( ) > conditionals inside a || ( ) group should be avoided. > > I wonder if the dependency couldn't be written like this, without the > amd64? () conditional: > > || ( > ( > >=dev-libs/glib-2.34.3:2[abi_x86_32(-)] > >=virtual/opengl-7.0-r1[abi_x86_32(-)] > ) > ( > app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)] > app-emulation/emul-linux-x86-opengl[-abi_x86_32(-)] > ) > ) > > emul-linux-x86-* doesn't have keywords other than amd64, so it won't > match on non-amd64 anyway. It would but I wanted to be on the safe side when one of the developers broke deps. I really don't want autounmask to try to keyword emul-linux-x86 on x86 :). But maybe '-*' in the ebuild is enough. As a note, something like this won't work properly because of portage's broken dep resolver: || ( dev-libs/foo[abi_x86_32(-)] dev-libs/foo[abi_ppc_32(-)] ) -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Multilib project newsletter #n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/07/14 01:24 AM, Ulrich Mueller wrote: >> On Tue, 01 Jul 2014, Ian Stakenvicius wrote: > >> On 01/07/14 06:44 PM, Ciaran McCreesh wrote: || ( amd64? ( >>> >>> I thought we were trying to discourage that abomination... > >> It's still necessary, unfortunately, until such time as >> everything in the tree no longer needs/depends on the emul-* >> packages (see news item #8 for progress). Otherwise, end-users >> would end up with dependency collisions. > > Sure, the second block is needed, but the point is that foo? ( ) > conditionals inside a || ( ) group should be avoided. > Ahh, sorry, missed that point entirely. > I wonder if the dependency couldn't be written like this, without > the amd64? () conditional: > > || ( ( >> =dev-libs/glib-2.34.3:2[abi_x86_32(-)] >> =virtual/opengl-7.0-r1[abi_x86_32(-)] > ) ( app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)] > app-emulation/emul-linux-x86-opengl[-abi_x86_32(-)] ) ) > > emul-linux-x86-* doesn't have keywords other than amd64, so it > won't match on non-amd64 anyway. > LGTM, will test tomorrow and confirm. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOzm3cACgkQ2ugaI38ACPCloQD/fKfmTkG9yp+e/D+tK7Xmiepb SKPlIk9tcoUzF0h8aToBAIqAjG8hcRKzuwoHOytpEekxVV29HWgWe+2xD6Q37T/r =XYoV -END PGP SIGNATURE-
Re: [gentoo-dev] Multilib project newsletter #n
> On Tue, 01 Jul 2014, Ian Stakenvicius wrote: > On 01/07/14 06:44 PM, Ciaran McCreesh wrote: >>> || ( amd64? ( >> >> I thought we were trying to discourage that abomination... > It's still necessary, unfortunately, until such time as everything > in the tree no longer needs/depends on the emul-* packages (see news > item #8 for progress). Otherwise, end-users would end up with > dependency collisions. Sure, the second block is needed, but the point is that foo? ( ) conditionals inside a || ( ) group should be avoided. I wonder if the dependency couldn't be written like this, without the amd64? () conditional: || ( ( >=dev-libs/glib-2.34.3:2[abi_x86_32(-)] >=virtual/opengl-7.0-r1[abi_x86_32(-)] ) ( app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)] app-emulation/emul-linux-x86-opengl[-abi_x86_32(-)] ) ) emul-linux-x86-* doesn't have keywords other than amd64, so it won't match on non-amd64 anyway. Ulrich pgpOHbIf0x_q9.pgp Description: PGP signature
Re: [gentoo-dev] Multilib project newsletter #n
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/07/14 06:44 PM, Ciaran McCreesh wrote: > On Wed, 2 Jul 2014 00:38:53 +0200 Michał Górny > wrote: >> || ( amd64? ( > > I thought we were trying to discourage that abomination... > It's still necessary, unfortunately, until such time as everything in the tree no longer needs/depends on the emul-* packages (see news item #8 for progress). Otherwise, end-users would end up with dependency collisions. However, with the way dependencies can be ordered now, once emul-* packages are lastrite'd we can finally drop that from all of the ebuilds. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlOzeuUACgkQ2ugaI38ACPDiqQD+LFuZVwv7bsaw78iISRQ8dc+l pFU+8HnJ2zMuQe7ntmwBAJ2keeY9QKAd0i1Cztv0HaBHoafXH6ld/BmkT1onA7Q1 =jJfw -END PGP SIGNATURE-
Re: [gentoo-dev] Multilib project newsletter #n
On Wed, 2 Jul 2014 00:38:53 +0200 Michał Górny wrote: > || ( > amd64? ( I thought we were trying to discourage that abomination... -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Multilib project newsletter #n
Hello, developers and users.
I'm pretty sure that all of you are waiting with bated breaths for news
on the multilib project, so I've scrambled this quick newsletter
listing our latest achievements, issues and other things you may want
to know.
In random order:
1. hasufell fixed the header wrapping issues with libsdl that triggered
build failures in programs using SDL without pkg-/sdl-config [1]. Well,
to be more exact, he removed wrapping completely, and along with it
the x86 Hermes blitter assembly and support for libggi & directfb that
created differences in and is no longer available
in SDL2 anyway.
2. pesa is still working on Qt4 in the project overlay [2]. He's making
progress all the time but there's still a lot to do -- and if you're
wondering, the current version doesn't support multilib properly yet
(fails on wrapped headers for a start).
3. Conversions of the remaining emul-linux-x86 libraries are stalled
as 'likely unnecessary'. In other words, please do not enable multilib
on some package just because it was in emul-linux-x86 since the dawn
of Gentoo. Convert it only when something else requires it.
4. I cleaned up all arch/ profiles to support multilib consistently,
and blueness handled most of hardened/*/{musl,uclibc}. A matrix of what
needed to be done is on the wiki [4]. Most importantly, this means that
from now on you can consistently match ${ABI} inside ebuilds
independently of whether the profile is multilib or not. In multilib
ebuilds you can also match ${MULTILIB_ABI_FLAG} (TODO: export it
globally as well for non-multilib ebuilds?).
5. We (I and _AxS_) also made the native ABI flag implicit USE. This
means that from now on, every ebuild on x86 pretends to have abi_x86_32
-- even if it's not multilib. This allows the USE-deps to match earlier
versions of packages for people who do not need multilib.
6. _AxS_ found out that -- thanks to the above -- we can write
dependencies for x86 binary packages much simpler. Some details are
on the wiki [5]. Long story short, the modern deps go like:
|| (
(
>=dev-libs/glib-2.34.3:2[abi_x86_32(-)]
>=virtual/opengl-7.0-r1[abi_x86_32(-)]
)
amd64? (
app-emulation/emul-linux-x86-baselibs[-abi_x86_32(-)]
app-emulation/emul-linux-x86-opengl[-abi_x86_32(-)]
)
)
Once the emul-linux-x86 are gone, it will be enough to drop
the 'amd64?' block and the outer || ().
7. I have made sys-libs/lib-compat installable on amd64 and replaced
emul-linux-x86-compat with a metapackage (since the two installed
the same binary thing). I've also fixed sys-libs/lib-compat-loki to
install its libraries in lib32 rather than lib64 (QA, whert art
thou?!). Note that this may break stuff that relied on the wrong
location but we're likely going to p.mask both for security
and license issues anyway [6,7,8].
8. We also started fixing ebuilds to support multilib deps but it's
really hard work. There is a progress tracker on the wiki [9] but it
lists only packages that depend on emul-linux-x86... and there are
32-bit games keyworded amd64 with no emul-linux-x86 deps. And most of
games have incorrect, broken, mis-synced and otherwise horrible deps
anyway.
9. Following some known shortcomings and a Funtoo request, I've added
'exception' support to multilib-dep-fixor [10]. In particular, it
allows us to force lower-known-safe versions of packages than it used
to put before. If you feel like it goes too high, and you know EAPI=5
(or multilib) was there for a long time, please suggest adding another
exception.
10. Oh, and in case anyone was wondering -- stable tree is still
silently broken, and arch teams are slacking in fixing the remaining
stabilizations [11]. Would someone mind dropping some of the packages
back to ~arch?
11. If all goes well, we may be able to mask emul-linux-x86 for removal
this summer.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=512430
[2]:http://git.overlays.gentoo.org/gitweb/?p=proj/qt.git;a=summary
[3]:https://bugs.gentoo.org/show_bug.cgi?id=510042
[4]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Profile_fixing_status
[5]:https://wiki.gentoo.org/wiki/Project:Multilib/Tips_%26_tricks#Binary_Package_Dependencies
[6]:https://bugs.gentoo.org/show_bug.cgi?id=510960
[7]:https://bugs.gentoo.org/show_bug.cgi?id=510962
[8]:https://bugs.gentoo.org/show_bug.cgi?id=504952
[9]:https://wiki.gentoo.org/wiki/Multilib_porting_status#Dependency_update_status
[10]:https://bitbucket.org/mgorny/multilib-dep-fixor
[11]:https://bugs.gentoo.org/show_bug.cgi?id=507148
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
