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--