FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-06-2012, 01:30 PM
Ian Stakenvicius
 
Default About forcing rebuilds of other packages issue

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

On 06/09/12 09:25 AM, Ian Stakenvicius wrote:
>
> 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.
>
>

..i have no idea what "replate" was supposed to be. I think i meant
to type "equate"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBIpX4ACgkQ2ugaI38ACPC0jwD6A6PMqQHV/8sWZnqSm2hF/plD
iBrZRvAxH7T0YdjQKeMA/02YFiom8mHs0GUDKUe18PkzM5aBlGKbnYyYcwcD3eOO
=1cGg
-----END PGP SIGNATURE-----
 
Old 09-06-2012, 04:40 PM
Zac Medico
 
Default About forcing rebuilds of other packages issue

On 09/06/2012 02:01 AM, Fabian Groffen wrote:
> After reading this thread, I have seen numerous occasions where has been
> asked what this proposal actually solves. Unless I've accidentially
> skipped over it, the answer has yet to be given. It appears to me now
> sub-slot is a feature that makes it easy to express a situation that
> could be expressed today as well, but requiring more work. As such
> "syntactic sugar", it seems not well bounded, allowing possibly for
> doing things that result in a big mess (I cannot prove this atm, and
> there is no specification afaict.)

The sub-slot is needed for those cases where it's just not practical to
bump the regular slot. Tiziano Müller (dev-zero) has summarized the
possible solutions well [1]:

> I see four possibilities:
> 1) patch them to version the headers as well and slot them (together with slot operator deps)
> 2) ask upstream to properly version the headers alongside with the lib and slot them (together with slot operator deps)
> 3) slot them and block old slots in newer versions (together with slot operator deps)
> 4) introduce a new EAPI variable which can be incremented whenever an soname changes (needs some more thinking and proper specification, somehow duplicates SLOT)

Sub-slot implements #4 (by extending the SLOT variable instead of using
a new variable).

[1] https://bugs.gentoo.org/show_bug.cgi?id=414955#c10
--
Thanks,
Zac
 
Old 09-07-2012, 05:13 PM
Fabian Groffen
 
Default About forcing rebuilds of other packages issue

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=e4ba8f36e6a4624f4fec61c7ce8 bed0e3bd2fa01
[2] http://wiki.gentoo.org/wiki/EAPI_5_tentative_features

--
Fabian Groffen
Gentoo on a different level
 
Old 09-07-2012, 05:51 PM
Ian Stakenvicius
 
Default About forcing rebuilds of other packages issue

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

iF4EAREIAAYFAlBKNBwACgkQ2ugaI38ACPBsOQEAsFeayfviF7 43E9+6M06nRFiN
Zoz58P1VIIUxR8QdqEoA/RU7OaoIlMDbTOAwuxIuRY2lj0hUI2zVfCk09u58l1Yv
=zKWs
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 05:52 PM
Zac Medico
 
Default About forcing rebuilds of other packages issue

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/07/2012 10:13 AM, Fabian Groffen wrote:
> Could you give an example where implicit ${PV} as sub-slot would
> not do what you need?

Can you point out a package for which SONAME/ABI/whatever changes
every time ${PV} changes? Probably not. Is the relationship between
${PV} and SONAME/ABI/whatever changes the same for every package?
Absolutely not. So, we have to be able to bump the sub-slot when it's
appropriate for the particular package, and every package is different.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBKNEoACgkQ/ejvha5XGaOvAQCfZS/TAtDijXFox9cHi3BkjKgP
raYAoJL77bi09/dABH3brj+2LjWYbydK
=sIAY
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 05:59 PM
Fabian Groffen
 
Default About forcing rebuilds of other packages issue

On 07-09-2012 10:52:10 -0700, Zac Medico wrote:
> On 09/07/2012 10:13 AM, Fabian Groffen wrote:
> > Could you give an example where implicit ${PV} as sub-slot would
> > not do what you need?
>
> Can you point out a package for which SONAME/ABI/whatever changes
> every time ${PV} changes? Probably not. Is the relationship between
> ${PV} and SONAME/ABI/whatever changes the same for every package?
> Absolutely not. So, we have to be able to bump the sub-slot when it's
> appropriate for the particular package, and every package is different.

I'm sure there are such packages, but I guess you're right. It's good
to have this clear.


--
Fabian Groffen
Gentoo on a different level
 

Thread Tools




All times are GMT. The time now is 07:11 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org