On 07-09-2012 13:51:24 -0400, Ian Stakenvicius wrote: > On 07/09/12 01:13 PM, Fabian Groffen wrote: > > On 06-09-2012 09:25:53 -0400, Ian Stakenvicius wrote: > >> #1 - there is both a specification, and an initial > >> implementation, AND a fork of the tree that is kept > >> semi-up-to-date on my dev overlay. > > > > I was interested in a (formal) specification, not a proof of > > concept. > > > > Ahh.. sorry, i figured the modified slot-operator spec that Ciaran > and Zac did was considered formal. Are you looking for a GLEP, then? > or...
No, not a GLEP, per se. I'm trying to understand what sub-slot does and
is. I think I'm starting to understand now. However, for this feature
to be added to an EAPI, IMO it would be nice if there are resources that
make it for most developers very clear how this feature should be used
(and how not), and what kind of problems it can solve.
I guess real-life examples, more extensively described than you did
before, with exactly where it goes wrong, and how the situation is
improved would help.
> if you s/slot-deps/slot-operators/ , then yes i'm aware. to me,
> "slot-deps" is something we got in (iirc) EAPI=2.
The wiki calls it "Slot operator dependencies", which I abbreviate dto
slot-deps. Sorry for the confusion.
> >> [1] No advantage as sub-slots wouldn't relate to this, UNLESS
> >> the masking would then remove -all- SLOT="0/5" versions from the
> >> tree. In that case, the old SLOT="0/3" provider would be the
> >> 'upgrade' path and so 'foo' and 'bar' would be triggered for
> >> rebuild (since the lib they were linked to would be disappearing
> >> during emerge -uDN)
> >
> > So your example SLOTs are wrong, and should have included the
> > minor (always!?!) since downgrading a lib that goes back to an
> > older minor means functions no longer exist, thus a consumer can
> > potentially break.
>
> If those (missing) functions are necessary then the either the full
> slot, or the particular minimum package version, of libfnord would
> need to be specified in the consumer. This isn't any different from
> how things work now.
Eh, no. Now it just always breaks when you perform a downgrade, and
revdev-rebuild or @preserved-libs won't help you. I prefer that you
give best practices how to use sub-slots to make Portage also able to do
a recompile of bar when libfnord in the same SLOT gets downgraded.
(Because minors are used for compatible changes -- additions -- to the
ABI.)
(And the recompile is preferably done against the headers of the
downgraded version, but with the newer version's lib still around, such
that if this is a vital binary such as Python, it will not break down --
however, this is most likely too much to ask.)
> This is why, for the rebuild of bar-2.4 to be triggered on upgrade to
> libfnord-3.5 the SLOT= var within libfnord-3.5.ebuild would need to
> have something other than SLOT="0/5", ie, SLOT="0/5.12"
Yeah, but can I also avoid bar-2.4 being recompiled when I install
libfnord-3.5? It's not necessary, because the 5-ABI of libfnord is
supposed to be backwards compatible. (At least that's the idea.)
Like mentioned before, I DO want bar-2.4 to be recompiled if I have to
downgrade libfnord to a version before the one I had installed when I
compiled bar-2.4, though.
> > Do you allow sub-slot to depend on e.g. USE-flags in use? Suppose
> > libfnord has a USE-flag cow that adds special cow interfaces to
> > the ABI/API. Would SLOT="X/${PV}$(use cow && echo -- -cow)" work?
> > (I think SLOT is supposed to be metadata-static, but does the
> > sub-slot part count to that?)
>
> No, afaik slots (including sub-slots) can't be dynamic. Plus we
> already have comprehensive use deps solutions so why would we need that?
Because the ABI changes. But I guess you're right that we can safely
ignore packages that screw it up badly enough here.
Thanks
--
Fabian Groffen
Gentoo on a different level
signature.asc
Description: Digital signature
