From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-65461-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id D37361387FD for <garchives@archives.gentoo.org>; Sat, 29 Mar 2014 08:35:07 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A3319E0B2F; Sat, 29 Mar 2014 08:34:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 9ECECE0B27 for <gentoo-dev@lists.gentoo.org>; Sat, 29 Mar 2014 08:34:54 +0000 (UTC) Received: from pomiot.lan (77-254-69-105.adsl.inetia.pl [77.254.69.105]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 6B5A933FDD3; Sat, 29 Mar 2014 08:34:52 +0000 (UTC) Date: Sat, 29 Mar 2014 09:34:39 +0100 From: =?ISO-8859-2?B?TWljaGGzIEfzcm55?= <mgorny@gentoo.org> To: gentoo-dev@lists.gentoo.org Cc: rich0@gentoo.org Subject: Re: [gentoo-dev] New virtuals for libudev and libgudev Message-ID: <20140329093439.3b5d3e1e@pomiot.lan> In-Reply-To: <CAGfcS_nAbwTAousyzbXKA0=QQnX3CMqywnxGKmQWozT1KY=5SQ@mail.gmail.com> References: <5335EE26.1010606@gentoo.org> <CAGfcS_nAbwTAousyzbXKA0=QQnX3CMqywnxGKmQWozT1KY=5SQ@mail.gmail.com> Organization: Gentoo X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/eAfSRa6w7VwTpbT_y7l6L+E"; protocol="application/pgp-signature" X-Archives-Salt: 363821f5-cdd2-45a4-b082-3bae90ac802c X-Archives-Hash: ee9511d063919c407c91ba9ff2c8bc8a --Sig_/eAfSRa6w7VwTpbT_y7l6L+E Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Dnia 2014-03-28, o godz. 19:53:07 Rich Freeman <rich0@gentoo.org> napisa=B3(a): > On Fri, Mar 28, 2014 at 5:48 PM, Rick "Zero_Chaos" Farina > <zerochaos@gentoo.org> wrote: > > All in all, this isn't a bad idea on the surface, but the first > > arguement shows immediately when this is scaled up. How many other > > packages have multiple libs with different sonames? Off hand, I can > > think of poplar, but I'm sure there must be more. Is it really > > scalable, desirable, or sane, to break each package on the system into > > multiple different virtuals like this? >=20 > Clever idea, actually, though I'd be interested in whether anybody > else can think of any unintended consequences. >=20 > I agree that there could end up being many cases of this, but that > really just amounts to clutter, and more granular dependencies (which > also make me think that a next step could actually be packages that > only install the necessary libraries, and somehow controlling this by > dependencies rather than USE flags which are a bit more cumbersome). This is the other side of this. People already requested libudev without whole udev, and this is a way of allowing it in the future. > There really isn't anything special about virtual packages other than > the fact that they don't install anything. I wonder if it would make > sense to actually create a new category for virtuals that only exist > to express library dependencies. Functionally it would be no > different, but it would split up the namespace so that we don't have > an additional 193 packages in the virtual category. Plus, when > looking at ebuilds it will be a bit more clear what each dependency is > actually pulling in. I have already suggested separate category for perl virtuals but been quieted down at the time. I doubt people really want another category for virtuals since some of their poor tools rely on 'virtual/'. > One thing you didn't mention in your email is the interaction with > conventional virtuals. The dep string for libudev reads: > RDEPEND=3D" > || ( > >=3Dsys-fs/udev-208:0/0[${MULTILIB_USEDEP},static-libs?] > >=3Dsys-apps/systemd-208:0/2[${MULTILIB_USEDEP},static-li= bs(-)?] > >=3Dsys-apps/systemd-208:0/1[${MULTILIB_USEDEP},static-li= bs(-)?] > >=3Dsys-apps/systemd-208:0/0[${MULTILIB_USEDEP},static-li= bs(-)?] > >=3Dsys-fs/eudev-1.3:0/0[${MULTILIB_USEDEP},static-libs?] > )" >=20 > What happens if eudev-209 and udev-209 don't bundle the sane SONAME > for libudev, and thus need different subslots? The virtual libudev is > versioned 208. There's an exact subslot dep in there (:M/N). If either of them changes SONAME of any of the libraries, the provider subslot is bumped and the virtual no longer matches it. The systemd deps are a good example of that. The subslots 0, 1 and 2 correspond to changes in libsystemd.so. Now, if any of SONAMES in systemd change, it will have subslot 3 and the virtual will no longer match. If it's libudev or libgudev changing, we'd introduce a new version (subslot) of the virtual; otherwise, a new revision with systemd:0/3 added. In fact, the versions are not even really necessary there. --=20 Best regards, Micha=B3 G=F3rny --Sig_/eAfSRa6w7VwTpbT_y7l6L+E Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQJ8BAEBCgBmBQJTNoWfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2REJCMDdDQzRGMERBRDA2RUEwQUZFNDFC MDdBMUFFQUVGQjQ0NjRFAAoJELB6GurvtEZOCZgQALzjiSdGdReuF4ztHSKc2KUJ 9v3vRl+zBkT4vkQsZ6cDcxtPqYN4gJz1vR/h36GSi/K3TjeMtwlmDq668KGQKnyK Cy1PexBNstdDPrLSBzhoPCBblPjNcpzvbesnYMj8ZZ6I/NSKQRIbMX4uy5OiBqoi K7vreBjowXv3pK280zobGZ0E+7neg6+kYJ6Sb6LaSNMf7p5MtkxrPROIAcL8vwwO B11OT4Yj4NxnRFfxZv6+IUKhc9O1L7p6SyaODrcbANLKq1GS4cC5s8mdc8uSM0WL dMofqtVtCnYNE1wkAUMuHK9Gt8Mv79jGWBrZKzykvCOUywAgKImdZ17XNRY51I8k Er56u3OsEhv6K3Rws2bJYpPkINB+xMUmLg7gDxaKNXpMV+CzTFuK2PyCrQmMEtyq Yu2SqtYqbdiQKxbXQy+bqOw5n0j6OgTEPwC3CMvMxIydiWmJka5VLCcgjdF7K2qR m1w2EVl3pCZi0qOAaSZZEIZ7jQE76+d0rsBaAFCmQDiVu8bd+J+jTW69BiFTCXI+ z4A/tMCKU/x1IsRRP1J262pTc2/Gd6xznb3wV9v3ophDGFKrV/ex+ZL/UGeeZ/SF zYNog8Pbj7JyeP0IAoGE0Y8xMJ00/Zy0JTnMfShW1inL42O+ewLF67KrXDB9e6P9 jOn0hm096RdqfpP6XJrX =SBTQ -----END PGP SIGNATURE----- --Sig_/eAfSRa6w7VwTpbT_y7l6L+E--