From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id F0B1C1381F3 for ; Fri, 12 Apr 2013 16:26:04 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A4F0CE098E; Fri, 12 Apr 2013 16:25:51 +0000 (UTC) Received: from vms173011pub.verizon.net (vms173011pub.verizon.net [206.46.173.11]) by pigeon.gentoo.org (Postfix) with ESMTP id B7791E0983 for ; Fri, 12 Apr 2013 16:25:50 +0000 (UTC) Received: from odin.tremily.us ([unknown] [72.68.100.81]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0ML500FLUHMS5B80@vms173011.mailsrvcs.net> for gentoo-dev@lists.gentoo.org; Fri, 12 Apr 2013 11:25:41 -0500 (CDT) Received: by odin.tremily.us (Postfix, from userid 1000) id 797B5967596; Fri, 12 Apr 2013 12:25:40 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tremily.us; s=odin; t=1365783940; bh=PHQhZBirCIm+Ye0KCTcPYcTl+DoCmO2MNlh1UYzqE8Y=; h=Date:From:To:Subject:References:In-Reply-To; b=oHDqFeLhwMzzCMmPE5oVkhskb+WFQny6rDYpXXB3p4d2izQOQggwbWpfUThkmPB3V 4UbohuKalmf9kvwsIJeYU0w2rTh15TaWKpONsJzERgtC2hX7mZM5lMRlxSFwKs67V/ mAHOWOe9cfrVU3eMQAeCLDSfr6mQkBOhitPn1V6E= Date: Fri, 12 Apr 2013 12:25:40 -0400 From: "W. Trevor King" To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Binary package dependencies for sub-slot-less EAPIs Message-id: <20130412162540.GB13054@odin.tremily.us> References: <20121012125315.33500bbb@sera-17.lan> <20121012211023.592e82a1@gentoo.org> <20121013082820.75d280a1@sera-17.lan> <20121016234230.3b79a2fe@gentoo.org> <1350495278.2447.33.camel@belkin4> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=eAbsdosE1cNLO4uF Content-disposition: inline In-reply-to: OpenPGP: id=39A2F3FA2AB17E5D8764F388FC29BDCDF15F5BE8; url=http://tremily.us/pubkey.txt User-Agent: Mutt/1.5.21 (2010-09-15) X-Archives-Salt: 92dee849-db60-44ae-b440-81f9e744e133 X-Archives-Hash: 57ac3fe11eeb853029d4ddf4e6d6e2c3 --eAbsdosE1cNLO4uF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Over on #gentoo-releng and in gentoo-catalyst@ we've been running into binary package dependency problems [1]. Before EAPI-5 and sub-slots, the version of dependency packages is not recorded in the binary package metadata (the Packages file). For example, a binary package for GCC built against mpc-0.8.2 will link to libmpc.so.2. If you install that package on a system that only has mpc-1.0.1 (and thus, libmpc.so.3), your cc1 will crash because libmpc.so.2 is missing. What we need is a way to track ABI sub-slot dependencies for all packages, even those that currently use EAPI-0. My initial idea was to store a fake EAPI-5-style sub-slot information in the binary package metadata, but further discussion on #gentoo-portage pointed me at the toolchain folks: 10:33 < zmedico> dol-sen: wouldn't it be easier to just migrate those pkgs to EAPI 5 + slot-operator? 10:34 * zmedico doesn't feel like doing extra work when EAPI 5 already does everything we need =E2=80=A6 11:16 < Tommy[D]_> Zero_Chaos: my suggestion: ask the toolchain guys about their preferred way (like updating existing eclass, using a new eclass, moving code into ebuilds) and when you got that, do the needed work, including an EAPI-5 version of toolchain ebuilds I looked in bugzilla for requests to update the toolchain EAPIs, but didn't find anything [2]. I don't want to bother people if the issue had already been hashed out, and searching on Gmane turned up the =E2=80=9C[RFC] Drop EAPI=3D0 requirement for system packages.=E2=80=9D thre= ad from last October [3]. This early comment from Rich seemed to summarize the anti-EAPI-bump camp: On Wed, Oct 17, 2012 at 03:00:12PM -0400, Rich Freeman wrote: > A policy that says all new ebuilds shall use EAPI foo might result in > fewer new ebuilds. Sure, they'll have new and shiny fooness, but > arguably I'd rather have more packages supported on older EAPIs then > fewer packages supported on newer ones. >=20 > Again, as I stated before, things that actually benefit the end users > like slot dependencies are fine to mandate when it makes sense to do > so. In other words, =E2=80=9CWhy force folks to do this if there is no benefit?= =E2=80=9D. This is understandable, but I think the broken binary packages [1] are enough of a visible benefit. The thread suggested filing bugs for bumping effected packages, but for this issue =E2=80=9Ceffected packages=E2= =80=9D is =E2=80=9Canything you might want to distribute as a binary package that uses something without EAPI-5 sub-slots=E2=80=9D [4]. I'm happy to start filing bugs, but that doesn't strike me as the most productive way forward. If anyone can think of other solutions besides tweaking Portage or bumping a bunch of package EAPIs, I'd be happy to hear them ;). Otherwise I'd be happy to hear suggestions about moving forward on at least one of those fronts. Since I seem to be the most bothered by this issue, it's only fair that I help with the itch scratching. I just need a roadmap from the folks with commit access so I can start chipping away at whichever solution y'all think looks most appealing ;). Cheers, Trevor [1]: http://thread.gmane.org/gmane.linux.gentoo.catalyst/2137/focus=3D2237 [2]: https://bugs.gentoo.org/buglist.cgi?short_desc=3DEAPI&resolution=3D---= &query_format=3Dadvanced&bug_status=3DUNCONFIRMED&bug_status=3DCONFIRMED&bu= g_status=3DIN_PROGRESS&bug_status=3DRESOLVED&bug_status=3DVERIFIED&short_de= sc_type=3Dallwordssubstr&component=3DCore%20system&component=3DDevelopment&= component=3DCore%20system&component=3DDevelopment&product=3DGentoo%20Linux [3]: http://thread.gmane.org/gmane.linux.gentoo.devel/80705 [4]: Although on the catalyst side, only @system is really important. --=20 This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy --eAbsdosE1cNLO4uF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRaDWAAAoJEEUbTsx0l5OMxW8P/AkPLzZ5UVDsjnyDgI2NI2xe UuXZ0uTw9Ukq0PQldrk8JMa3dCCPqTL+na0VykyDUbA4B+jnJIdUo/T8Rpc8Eic9 BAbviUnvYA8eSsrbui7EKhVqEw3mPvHnFtSWuxI0dqR59fou3aSrv5reqT9qf7ex qn9xHk+gV/8eovcGVcenl2fmE9NIljW2ZruJuuGAYO9v+WeVzvUQ3tdhziYDOm8w azaJp2hwP2q+mefa1canpvFLJpwVfv8Koi1DyVka/de5MNW+PDI6v6wHqO8Awwh9 Sm9X5DRSe9vyLqwftNusXl03Z0jCfjKTjLa6lrbGHzhDjHxXdoFnskDWa/blOP7b LO8QlaMfSc2O0JRKCaEePekJrc4dlgX8mn688Y9NMwW75WE1cg6yWMBRf+qmJvHh TP2f0sW1VKSFeL6M9z8t13SXGu/sHU+3JWHFRRulGyR7fdILxnQi0APjrx/bMaOi lRI5FMO61G9B7VPr1ZNPYCUaV7Wzp1WL5ad5CO1ue1IiS2kK4t20ko3Mj6i1f+14 1Nejs19pHP7mR+Mo60dvNKcLNiMlYg6phzRXVtdEnWJ5lG3dA7nYpbf0I3qlZQzq xaFTMIpwvEvz71rwwdTgoEwbAhH6veiIxKxu4d8vdSMFSdYv7ITipoeCogvWR9Rf 4C6ls2aPldNuqoOMwf4j =GTyK -----END PGP SIGNATURE----- --eAbsdosE1cNLO4uF--