Gentoo Archives: gentoo-dev

From: Ian Stakenvicius <axs@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] About forcing rebuilds of other packages issue
Date: Thu, 07 Jun 2012 19:14:52
Message-Id: 4FD0FD7B.9020204@gentoo.org
In Reply to: Re: [gentoo-dev] About forcing rebuilds of other packages issue by Pacho Ramos
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA256
3
4 On 07/06/12 03:00 PM, Pacho Ramos wrote:
5 > El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió:
6 >> On Thu, 07 Jun 2012 20:43:54 +0200 Pacho Ramos <pacho@g.o>
7 >> wrote:
8 >>>> I would prefer, as a workaround, allow reverse deps to
9 >>>> RDEPEND on glib:2.* instead. That way it would cover more
10 >>>> cases when more than two slots are available
11 >>>
12 >>> Well, per:
13 >>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b
14 >>>
15 >>>
16 >>>
17 looks like "*" usage for SLOTs would be allowed :), or I am
18 >>> misinterpreting it?
19 >>
20 >> It's not a wildcard.
21 >>
22 >
23 > But it looks like a valid usage for cases like glib vs.
24 > dbus-glib/gobject-introspection I have exposed as example, and
25 > also allows us to keep "SLOT" over "ABI_SLOT" (at least for this
26 > case, not sure about others I could be missing now...)
27
28
29 How is the case of something like libpng going to be handled, where we
30 only support one API (and so only one SLOT)? Either in the proposed
31 ABI_SLOT thing or when using slot operators?
32
33 For the slot-operator case, will every consumer of libpng be forced to
34 change their dep to libpng:= to ensure they get rebuilt when libpng
35 bumps from 1.5 to 1.6??
36 -----BEGIN PGP SIGNATURE-----
37 Version: GnuPG v2.0.17 (GNU/Linux)
38
39 iF4EAREIAAYFAk/Q/XsACgkQ2ugaI38ACPCxWQEAgkx7C2PBK/awXvfA3RFolZQD
40 2K7G7cBboDvDexn/JogA/0W/ke62zz7Mtk/i6WLATIaUYRQ+8ViK2Y4J8n4C3yVZ
41 =SQX9
42 -----END PGP SIGNATURE-----

Replies

Subject Author
Re: [gentoo-dev] About forcing rebuilds of other packages issue Ciaran McCreesh <ciaran.mccreesh@××××××××××.com>