Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?

[Tom Wijsman <TomWij@gentoo.org>]

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

On Tue, 10 Dec 2013 16:06:51 -0500
Ian Stakenvicius <axs@gentoo.org> wrote:

> SLOT allows multiple versions of a package to be installed
> concurrently. In the case of libraries or dependencies, this supports
> the specific case where certain ebuilds only support a particular
> SLOT.  However, that doesn't mean that all packages need to be tied to
> one slot or another.

This discussion results in no change for the above paragraph; it will
still allow multiple versions to be installed, packages can still be
tied to multiple slots by specifying :*.

We're kind of discussion a problem here we don't know the answer to;
because in order to obtain numbers, we have to enumerate everything to
see how slots are being used. And only then we can determine that X%
would depend on a specific :${SLOT} and that (100-X)% would depend
on :*; the comparison here is what would suggest the default.

In another part in this thread we went looking for packages that
have multiple slots to judge; but, it comes to mind now that we might
want to look at the opposite which might be easier to study:

"What if we create multiple slots for libraries that have none?"

In order to do so, it again depends on how slots are being used:

"Why is a new slot made?"

One argument is "side-by-side install", another argument is "API
breakage" (eg. dev-java); some might only pick one argument or the
other, though what jumps to mind is that having the need for a
side-by-side install is the consequence of API breakage. Leading to:

"Do we create a new package or a new slot?"

It looks cleaner to me to have slots; because if you look at what a
"package" means, API breakages or major versions do not necessarily
mean it is a new package (depending on the way you look at it). 

> It should be noted here that this discussion is revolving entirely
> around multi-SLOT libraries.

Anything that fits a dependency relationship, thus almost entirely; as
shown in the other thread with those numbers there are some applications
that are also used as a dependency, that don't have to be a library.

> Firstly, there are packages like
> dev-db/postgresql that use SLOTs not just for library provision.

True, but I think we should look at the Portage tree at a wider scale
than bring up single examples; I think we have an example for multiple
variations, but how do we reflect the majority in the Portage tree?

> Secondly, SLOT= on the libraries being discussed may not actually be
> the correct method to deal with this at all, and rather, these libs
> should be using a subslot and the rdeps be using an upper-bound
> version on dependency atoms to limit which dependency it can be used
> with--it all depends on whether the library maintainer intends to
> support both major versions in the long term or not.

There are some varying thoughts wrt SLOT= here and there; looking at
what the devmanual says [1], it mentions: "Packages can support having
multiple versions installed simultaneously. This is useful for
libraries which may have changed interfaces between versions."

It almost seems as if it the combination of those both is the only
reason for the usage of SLOT= in the context of dependencies and/or
libraries. In this context, are there others one can think of?

That same page of the devmanual covers sub slots, it says [1]:
"Sometimes a package installs a library that changes interfaces between
versions, but it's undesirable or inconvenient to allow some of these
versions to be installed simultaneously. "

What is written here is different than our context; because we're
trying to have multiple slots here, and sub slots do the opposite.

 [1]: http://devmanual.gentoo.org/general-concepts/slotting

- -- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJSp6UoAAoJEJWyH81tNOV9i70H/jjM+EHLIn8uRwdO/G1XU226
gWpow/6D8mB5nwbbZJR3Zu6fH8JX7+sJbPuYlvJYzy2IYX67UH2PHsgbnFqxjhpa
/6EDi/MTtbL/0RdqbY15WkqOljl2+74vnwzctMnJSOQMCgKXVpFOiOT+XQxuPvGd
aFKlUE6wZZVQRrqb+Eb8VAvQx7ob+3ez9EUzzAY213uicIXL/n2h6GGS4+Bj1h5Z
7MOs4whuvQXbC94jdLCsoiMozau3ChpxZFhovFLfXGo1Nqg2rruxtld7KVsN+pIr
0mr+4mNnmMooZ1KUKP26RsY8kDvtoEI1GQZ81CmCh1acKMpvDUwjpv8mORb0sBU=
=5EzT
-----END PGP SIGNATURE-----