Re: [gentoo-dev] [gentoo-portage-dev] About forcing rebuilds of other packages issue

[Fabian Groffen <grobian@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5079 bytes --]

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.

> #2 - related to your question about what the proposal solves -- in my
> opinion, the biggest thing the proposal solves is the case where we
> want the ability to use SLOTs in the tree to manage and track
> dependency changes (ie, when an API or ABI has changed), but NOT allow
> multiple versions of a package to be installed at the same time.
> Further to this, it allows PMs to determine what needs to be rebuilt
> due to the old (no longer existing) dep being supported prior to said
> dep actually being removed.

...

> sub-slots is the 'some-identifier' part of ${SLOT}/${some-identifier}.
>  It doesn't have to replate to ${PV} at all, and generally shouldn't.
>  More likely it should relate to the ${major}.${minor} in the main
> library's SONAME.  For non-libtool dependencies some other form of id
> is used, ie for perl I used the major.minor from $PV.

> EAPI="4-slot-deps" is new to me; the implementation i've been testing

You refer to it lateron, so it seems to me you're unaware your sub-slots
and slot-deps are made as one commit [1].

> is EAPI="4-slot-abi" which is sub-slots and slot operators.  This is
> the spec that was written and proposed for EAPI=5 and so this is what
> i'll use to describe the above.

both are proposed for EAPI=5 [2]

> First, assuming currently libfnord is SLOT=0, and that there are no
> ABI/API breakages on libfnord-2 through libfnord-3.5, I would just use
> the ${major} version from the SONAME for the sub-slot. IE:
> 
> libfnord-1:SLOT="0/3"
> libfnord-2:SLOT="0/5"
> libfnord-2.1:SLOT="0/5"
> ...
> libfnord-3.5:SLOT="0/5"
> 
> And then, assuming that foo and bar both link in the usual way, IE
> they link against libfnord.so.3 instead of just libfnord.so , they

SONAME indeed refers to the versioned lib, although linking is of course
done against libfnord.so (-lfnord).

> both would RDEPEND as follows:
> 
> RDEPEND="app-cat/libfnord:="

This is "Slot operator dependencies" syntax.

> > (numeric indicators added): [1]What if libfnord-2.1 or libfnord-3.5
> > would be masked due to some problem not noticed prior to stabling
> > that makes it useless for many users. [2]bar-2.4 during configure
> > checks for a new function in libfnord-3.5 and uses it if available,
> > or uses an alternative code-path instead. [3]libfnord-2.1-r5 fixes
> > a crash in some function of the library. (Note: this whole
> > example/question sounds like an ebuild-quiz question that any dev
> > should be able to answer then.)
> > 
> > What would be the advantage of sub-slot here, assuming the
> > versioning of the libraries follows ABI versioning rules defined by
> > e.g. libtool.
> 
> [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.

> [2] In this case, the new ABI/API offering in libfnord-3.5 would need
> to be addressed in the SLOT, ie, SLOT="0/5.12".  As such when
> libfnord-3.5 would be upgraded then bar-2.4 (if it was already emerged
> of course) would be triggered for rebuild.  'foo' would afaik also be
> triggered for rebuild, though, as (at present) there isn't a way to
> match partial sub-slots (or sub-sub-slots, as it were) via the slot
> operators := and :*.

So you basically say: this is slot-dep, you store that bar-2.4 uses
libfnord-2.1.

> [3] No advantage, as linking would be consistent.  Sub-slots wouldn't
> be needed in this case, and afaict updating libfnord-2.1 to
> libfnord-2.1-r5 wouldn't trigger revdep-rebuild or require any
> additional mediation anyways.

Yes.

> Hope this helps clear things up..

I think I understand why ciaramn suggested the use of / iso SUB_SLOT (or
something like that) here.

Could you give an example where implicit ${PV} as sub-slot would not do
what you need?

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


[1] http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=e4ba8f36e6a4624f4fec61c7ce8bed0e3bd2fa01
[2] http://wiki.gentoo.org/wiki/EAPI_5_tentative_features

-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]