Gentoo Archives: gentoo-dev

From: Pacho Ramos <pacho@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] About forcing rebuilds of other packages issue
Date: Sat, 09 Jun 2012 10:54:48
Message-Id: 1339239212.2624.18.camel@belkin4
In Reply to: Re: [gentoo-dev] About forcing rebuilds of other packages issue by Pacho Ramos
1 El sáb, 09-06-2012 a las 12:46 +0200, Pacho Ramos escribió:
2 > El vie, 08-06-2012 a las 12:31 -0700, Zac Medico escribió:
3 > > On 06/08/2012 12:23 PM, Pacho Ramos wrote:
4 > > > El vie, 08-06-2012 a las 12:16 -0700, Zac Medico escribió:
5 > > >> On 06/08/2012 01:38 AM, Pacho Ramos wrote:
6 > > >>> El jue, 07-06-2012 a las 12:33 -0700, Zac Medico escribió:
7 > > >>>> On 06/07/2012 12:24 PM, Pacho Ramos wrote:
8 > > >>>>> El jue, 07-06-2012 a las 12:09 -0700, Zac Medico escribió:
9 > > >>>>>> On 06/07/2012 12:00 PM, Pacho Ramos wrote:
10 > > >>>>>>> El jue, 07-06-2012 a las 19:44 +0100, Ciaran McCreesh escribió:
11 > > >>>>>>>> On Thu, 07 Jun 2012 20:43:54 +0200
12 > > >>>>>>>> Pacho Ramos <pacho@g.o> wrote:
13 > > >>>>>>>>>> I would prefer, as a workaround, allow reverse deps to RDEPEND on
14 > > >>>>>>>>>> glib:2.* instead. That way it would cover more cases when more than
15 > > >>>>>>>>>> two slots are available
16 > > >>>>>>>>>
17 > > >>>>>>>>> Well, per:
18 > > >>>>>>>>> http://git.overlays.gentoo.org/gitweb/?p=proj/pms.git;a=commitdiff;h=f9f7729c047300e1924ad768a49c660e12c2f906;hp=b7750e67b4772c1064543defb7df6a556f09807b
19 > > >>>>>>>>>
20 > > >>>>>>>>> looks like "*" usage for SLOTs would be allowed :), or I am
21 > > >>>>>>>>> misinterpreting it?
22 > > >>>>>>>>
23 > > >>>>>>>> It's not a wildcard.
24 > > >>>>>>>>
25 > > >>>>>>>
26 > > >>>>>>> But it looks like a valid usage for cases like glib vs.
27 > > >>>>>>> dbus-glib/gobject-introspection I have exposed as example, and also
28 > > >>>>>>> allows us to keep "SLOT" over "ABI_SLOT" (at least for this case, not
29 > > >>>>>>> sure about others I could be missing now...)
30 > > >>>>>>
31 > > >>>>>> The :* operator doesn't trigger any rebuilds though. Quoting the PMS
32 > > >>>>>> patch that you linked:
33 > > >>>>>>
34 > > >>>>>> * Indicates that any slot value is acceptable. In addition, for runtime
35 > > >>>>>> dependencies, indicates that the package will not break if the matched
36 > > >>>>>> package is uninstalled and replaced by a different matching package in a
37 > > >>>>>> different slot.
38 > > >>>>>
39 > > >>>>> I mean, use it in conjunction with ":=", one for rebuild and other to
40 > > >>>>> indicate any 2.x SLOT fits the "normal" RDEPEND (to not need to
41 > > >>>>> periodically update RDEPENDs or need to go back from :SLOT depends to
42 > > >>>>> old =category/package-version-* ways)
43 > > >>>>>
44 > > >>>>> Allowing that, we wouldn't need ABI_SLOT (at least to prevent this issue
45 > > >>>>> that arises with using only SLOTs for this)
46 > > >>>>
47 > > >>>> What you're talking about here is more similar to ABI_SLOT operator deps
48 > > >>>> than what was originally intended for SLOT operator deps. In other
49 > > >>>> words, anyone who is opposed to ABI_SLOT operator deps is likely to also
50 > > >>>> be opposed to your proposal.
51 > > >>>
52 > > >>> Oh :(, and what is the reason to want to prevent this behavior? Looks
53 > > >>> much simpler to me than needing to use ranges for dependencies or
54 > > >>> needing to create "compat" packages to hide the problem :|
55 > > >>
56 > > >> It's close enough to ABI_SLOT that it would make more sense just to use
57 > > >> ABI_SLOT because it's more flexible.
58 > > >
59 > > > In that case, I think it's clear we need ABI_SLOT ;) The problem is how
60 > > > to document it in a way people agree with including it for eapi5 :|
61 > >
62 > > We can just write a specification for this one feature, and ask the
63 > > Council to approve it.
64 >
65 > That would be nice, if you remember, I started with "elog/ecommand
66 > splitting solution" to try to get this long standing issue solved "soon"
67 > and, since looks like each eapi takes more than a year to complete, I
68 > would really prefer to see it included in eapi5, specially after seeing
69 > that this "ABI_SLOT" idea was suggested years ago but the issue stalled
70 > later multiple times
71
72 Also, taking into account that all affected packages should start
73 migrating to eapi5 to really allow us to stop needing to use current
74 "tricks", would be much better to start as soon as possible instead of
75 waiting for another eapi cycle, that would delay "real solution" (I
76 mean, new eapi used by all affected packages in the tree) even more
77 months (or years)

Attachments

File name MIME type
signature.asc application/pgp-signature