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

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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


>> #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].
>

if you s/slot-deps/slot-operators/ , then yes i'm aware.  to me,
"slot-deps" is something we got in (iirc) EAPI=2.



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

When looking at the output of 'scanelf -n' on a binary or library,
dependent libs seem usually to be linked against libfnord.so.X rather
than libfnord.so ; hence the breakage when upgrading from a
libfnord.so.3 provider to a libfnord.so.5 provider.  I'm sure you're
aware of that, just trying to clarify what I meant above.


>> both would RDEPEND as follows:
>>
>> RDEPEND="app-cat/libfnord:="
>
> This is "Slot operator dependencies" syntax.
>

...and?

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

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.

IE, if foo works fine when being built against either libfnord-1 or
libfnord-2 , then the := slot operator will trigger a rebuild when
libfnord upgrades or downgrades.  That's its point.  If foo needs
functions that only libfnord-2 provides then it needs a dep of
> =libfnord-2 , or alternatively libfnord:0/5 .


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

No, we store that bar-2.4 uses libfnord:0/5

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"



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


Explicit ${PV} would result in needless rebuilds due to sub-slot
changes in your libfnord example above.  IE, there is no reason for a
package that has a basic RDEPEND="app-cat/libfnord:=" to be rebuilt
except when libfnord is upgraded from libfnord-1 to >libfnord-1 ;
whereas if ${PV} -were- to be the sub-slot, then rebuilds would happen
on every version bump.


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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKNBwACgkQ2ugaI38ACPBsOQEAsFeayfviF743E9+6M06nRFiN
Zoz58P1VIIUxR8QdqEoA/RU7OaoIlMDbTOAwuxIuRY2lj0hUI2zVfCk09u58l1Yv
=zKWs
-----END PGP SIGNATURE-----