| 1 |
-----BEGIN PGP SIGNED MESSAGE-----
|
| 2 |
Hash: SHA1
|
| 3 |
|
| 4 |
On Tue, 10 Dec 2013 16:06:51 -0500
|
| 5 |
Ian Stakenvicius <axs@g.o> wrote:
|
| 6 |
|
| 7 |
> SLOT allows multiple versions of a package to be installed |
| 8 |
> concurrently. In the case of libraries or dependencies, this supports |
| 9 |
> the specific case where certain ebuilds only support a particular |
| 10 |
> SLOT. However, that doesn't mean that all packages need to be tied to |
| 11 |
> one slot or another. |
| 12 |
|
| 13 |
This discussion results in no change for the above paragraph; it will
|
| 14 |
still allow multiple versions to be installed, packages can still be
|
| 15 |
tied to multiple slots by specifying :*.
|
| 16 |
|
| 17 |
We're kind of discussion a problem here we don't know the answer to;
|
| 18 |
because in order to obtain numbers, we have to enumerate everything to
|
| 19 |
see how slots are being used. And only then we can determine that X%
|
| 20 |
would depend on a specific :${SLOT} and that (100-X)% would depend
|
| 21 |
on :*; the comparison here is what would suggest the default.
|
| 22 |
|
| 23 |
In another part in this thread we went looking for packages that
|
| 24 |
have multiple slots to judge; but, it comes to mind now that we might
|
| 25 |
want to look at the opposite which might be easier to study:
|
| 26 |
|
| 27 |
"What if we create multiple slots for libraries that have none?"
|
| 28 |
|
| 29 |
In order to do so, it again depends on how slots are being used:
|
| 30 |
|
| 31 |
"Why is a new slot made?"
|
| 32 |
|
| 33 |
One argument is "side-by-side install", another argument is "API
|
| 34 |
breakage" (eg. dev-java); some might only pick one argument or the
|
| 35 |
other, though what jumps to mind is that having the need for a
|
| 36 |
side-by-side install is the consequence of API breakage. Leading to:
|
| 37 |
|
| 38 |
"Do we create a new package or a new slot?"
|
| 39 |
|
| 40 |
It looks cleaner to me to have slots; because if you look at what a
|
| 41 |
"package" means, API breakages or major versions do not necessarily
|
| 42 |
mean it is a new package (depending on the way you look at it).
|
| 43 |
|
| 44 |
> It should be noted here that this discussion is revolving entirely |
| 45 |
> around multi-SLOT libraries. |
| 46 |
|
| 47 |
Anything that fits a dependency relationship, thus almost entirely; as
|
| 48 |
shown in the other thread with those numbers there are some applications
|
| 49 |
that are also used as a dependency, that don't have to be a library.
|
| 50 |
|
| 51 |
> Firstly, there are packages like |
| 52 |
> dev-db/postgresql that use SLOTs not just for library provision. |
| 53 |
|
| 54 |
True, but I think we should look at the Portage tree at a wider scale
|
| 55 |
than bring up single examples; I think we have an example for multiple
|
| 56 |
variations, but how do we reflect the majority in the Portage tree?
|
| 57 |
|
| 58 |
> Secondly, SLOT= on the libraries being discussed may not actually be |
| 59 |
> the correct method to deal with this at all, and rather, these libs |
| 60 |
> should be using a subslot and the rdeps be using an upper-bound |
| 61 |
> version on dependency atoms to limit which dependency it can be used |
| 62 |
> with--it all depends on whether the library maintainer intends to |
| 63 |
> support both major versions in the long term or not. |
| 64 |
|
| 65 |
There are some varying thoughts wrt SLOT= here and there; looking at
|
| 66 |
what the devmanual says [1], it mentions: "Packages can support having
|
| 67 |
multiple versions installed simultaneously. This is useful for
|
| 68 |
libraries which may have changed interfaces between versions."
|
| 69 |
|
| 70 |
It almost seems as if it the combination of those both is the only
|
| 71 |
reason for the usage of SLOT= in the context of dependencies and/or
|
| 72 |
libraries. In this context, are there others one can think of?
|
| 73 |
|
| 74 |
That same page of the devmanual covers sub slots, it says [1]:
|
| 75 |
"Sometimes a package installs a library that changes interfaces between
|
| 76 |
versions, but it's undesirable or inconvenient to allow some of these
|
| 77 |
versions to be installed simultaneously. "
|
| 78 |
|
| 79 |
What is written here is different than our context; because we're
|
| 80 |
trying to have multiple slots here, and sub slots do the opposite.
|
| 81 |
|
| 82 |
[1]: http://devmanual.gentoo.org/general-concepts/slotting
|
| 83 |
|
| 84 |
- --
|
| 85 |
With kind regards,
|
| 86 |
|
| 87 |
Tom Wijsman (TomWij)
|
| 88 |
Gentoo Developer
|
| 89 |
|
| 90 |
E-mail address : TomWij@g.o
|
| 91 |
GPG Public Key : 6D34E57D
|
| 92 |
GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D
|
| 93 |
-----BEGIN PGP SIGNATURE-----
|
| 94 |
Version: GnuPG v2.0.22 (GNU/Linux)
|
| 95 |
|
| 96 |
iQEcBAEBAgAGBQJSp6UoAAoJEJWyH81tNOV9i70H/jjM+EHLIn8uRwdO/G1XU226
|
| 97 |
gWpow/6D8mB5nwbbZJR3Zu6fH8JX7+sJbPuYlvJYzy2IYX67UH2PHsgbnFqxjhpa
|
| 98 |
/6EDi/MTtbL/0RdqbY15WkqOljl2+74vnwzctMnJSOQMCgKXVpFOiOT+XQxuPvGd
|
| 99 |
aFKlUE6wZZVQRrqb+Eb8VAvQx7ob+3ez9EUzzAY213uicIXL/n2h6GGS4+Bj1h5Z
|
| 100 |
7MOs4whuvQXbC94jdLCsoiMozau3ChpxZFhovFLfXGo1Nqg2rruxtld7KVsN+pIr
|
| 101 |
0mr+4mNnmMooZ1KUKP26RsY8kDvtoEI1GQZ81CmCh1acKMpvDUwjpv8mORb0sBU=
|
| 102 |
=5EzT
|
| 103 |
-----END PGP SIGNATURE----- |
Archives