[gentoo-dev] Guidelines for using slot and sub-slot dependencies

[gentoo-dev] Guidelines for using slot and sub-slot dependencies

[Michał Górny]

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

Hello, all.

Considering the past experiences wrt slot, sub-slot and slot operator
dependencies, I'd like to write some kind of guidelines for using them.
I'd like to know your opinion on my 'draft' and possibly someone more
fluent in English to put them somewhere on the Wiki.


First of all, please remember that slots and sub-slots are just generic
tools. How they end up being used is up to the maintainer's discretion.
Therefore, always check how the package is slotted and sub-slotted
before depending on it. If it doesn't use sub-slots yet, use your
common sense or -- when in doubt -- ask the maintainer.

The goal of slot (and rarely sub-slot) dependencies is to limit
the number of package versions that can satisfy a dependency. The goal
of slot operator is to bind the package to the currently installed
version of a dependency and rebuild it when uninstalling that version.

So, the following questions need to be answered:

1. can any (current or possibly future) version of the package satisfy
your dependency?

2. does your package need to rebuilt when slot/sub-slot changes?

Of course, the answers depend on what exact purpose slots
and sub-slots serve on a package.


1. You almost always want to depend on a specific slot of a library.

This came up during the multilib work. If we are to support prebuilt
binary software, we need to be able to install the specific versions of
dependent libraries. As a result, so-called binary-only (runtime,
compat) slots are introduced.

An example of this is media-video/ffmpeg. It has a :0 slot that
corresponds to a complete ffmpeg install, and a :0.10 slot that
installs the libraries only. So every package that is being built
against ffmpeg, need to depend on slot :0.

It is likely that many more packages will grow binary-only slots
in the future. Therefore, it seems reasonable to depend on slot :0
(or a similar single slot) already.

Please specifically note that this not only applies to linking to
a library but also to using the tools provided by it during run-time.
So if your package uses 'ffmpeg' command-line tool, and depends on
'media-video/ffmpeg', portage will be able to uninstall the 'ffmpeg'
executable and leave your package silently broken.


2. You most often want := deps when linking to libraries.

Just check first how the library is sub-slotted. The commonly repeated
example, app-text/poppler, uses sub-slot for its low-level library
only. The high-level libraries that most programs use have stable APIs
and aren't supposed to have := deps.

If a particular package does not use sub-slots yet, use your common
sense. If it installs a single library only, you can use := dep. If it
installs libraries that changes their ABIs in approximately same
intervals, you can use the := dep.

Please remember to combine this with (1), so you'll often have :0=
as the actual dep.


3. You *can* depend on a specific sub-slot.

Most people seem not to know that but you can depend on sub-slots
the same way you depend on slots. This makes it possible to have
sub-slot versioned virtuals.

For example, virtual/udev-206-r3 (sub-slot 0) depends on:

  || ( ...
    >=sys-apps/systemd-206:0/1[...]
    >=sys-apps/systemd-206:0/0[...]
  )

which means that systemd sub-slots 1 & 0 have the same ABI of libudev.
Packages can depend on virtual/udev:= and expect the rebuild to be
propagated.


4. You *can not* trust portage's --dynamic-deps anymore.

This one is fairly important. In the past, we often assumed that
portage will 'update' deps from ebuilds automatically. This is no
longer correct if sub-slots are used -- since portage simply can't know
which sub-slot of the dependency was used to build the package.

This makes the point (1) above pretty important (see: the python-exec:2
issues). Since we don't have any proper tools to update dependencies of
installed packages (there's a future-eapi bug for that [1]), we need to
try harder to get them right.

[1]:https://bugs.gentoo.org/show_bug.cgi?id=486778

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Guidelines for using slot and sub-slot dependencies

[hasufell]

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

On 10/16/2013 02:59 PM, Michał Górny wrote:
> -- when in doubt -- ask the maintainer.
> 

We should just require maintainers to document what their slots and
subslots are for in the ebuild.

> 
> 4. You *can not* trust portage's --dynamic-deps anymore.
> 
> This one is fairly important. In the past, we often assumed that 
> portage will 'update' deps from ebuilds automatically. This is no 
> longer correct if sub-slots are used -- since portage simply can't
> know which sub-slot of the dependency was used to build the
> package.

so we should always revbump when introducing subslots?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJSXpBtAAoJEFpvPKfnPDWzMsoH/0CLsYBCRPk3vChM4tywIdBI
sIGEzzmvYeQcHqt4yZNfrSDZF1ACxNk3mrJsyW3E4NLVXU8m13FKh26yPyxpLXiX
BHZJ/+Yb4aiRRBNMY/39tI1MXm1QeVUmuYreVIeS0llpnfOKUFityJUwSKcoda96
sDxUcVwSLq+gPExKOpMV3aEc2moVUWWz/VPFaSRiKBDhbw61cfd+Vcg0pRWCmoT3
w5h1jPFF7z07RDtoz1dGJ0X3Ss4thd10pO2/bACSvuldgTCKbmcU3m42TWcGn+ya
ZIyRtOu3QLKZTPuP2N/S1K8A6qR/gqz/OOxKZztxTVvy2DgTuwXYyVhSsXuPJ1c=
=bF2i
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Guidelines for using slot and sub-slot dependencies

[Ian Stakenvicius]

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

On 16/10/13 09:11 AM, hasufell wrote:
> On 10/16/2013 02:59 PM, Michał Górny wrote:
>> 4. You *can not* trust portage's --dynamic-deps anymore.
> 
>> This one is fairly important. In the past, we often assumed that
>>  portage will 'update' deps from ebuilds automatically. This is
>> no longer correct if sub-slots are used -- since portage simply
>> can't know which sub-slot of the dependency was used to build
>> the package.
> 
> so we should always revbump when introducing subslots?
> 

Yes, but that's been recommended since the onset of EAPI=5 and
sub-slot/slot-operator deps, so hopefully this is nothing new.

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

iF4EAREIAAYFAlJeu24ACgkQ2ugaI38ACPAYEwD/S5I90mGXS3+z3jdflC5YoKi/
VUaL67/Q2SowHBqa+hcA/jtLhOwC7TCGansk5EYNpcCzMhDF1ALh49K18kGUldae
=Nbuy
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Guidelines for using slot and sub-slot dependencies

[Michał Górny]

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

Dnia 2013-10-16, o godz. 15:11:09
hasufell <hasufell@gentoo.org> napisał(a):

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 10/16/2013 02:59 PM, Michał Górny wrote:
> > -- when in doubt -- ask the maintainer.
> > 
> 
> We should just require maintainers to document what their slots and
> subslots are for in the ebuild.

I agree. However, this particular sentence was referring to packages
that don't have sub-slots yet.

> > 4. You *can not* trust portage's --dynamic-deps anymore.
> > 
> > This one is fairly important. In the past, we often assumed that 
> > portage will 'update' deps from ebuilds automatically. This is no 
> > longer correct if sub-slots are used -- since portage simply can't
> > know which sub-slot of the dependency was used to build the
> > package.
> 
> so we should always revbump when introducing subslots?

If you want them retroactively, yes. Of course, sometimes you may just
assume users will get them with the next version/revision.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 966 bytes --]

Re: [gentoo-dev] Guidelines for using slot and sub-slot dependencies

[Alexis Ballier]

I see this thread didn't get many answers; anyway, I agree with all
what you wrote and thank you for taking the time to write this down, so
a big +1 from me

Alexis.