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
signature.asc
Description: Digital signature