From: Tom Wijsman <TomWij@gentoo.org>
To: ulm@gentoo.org, gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?
Date: Tue, 10 Dec 2013 01:31:51 +0100 [thread overview]
Message-ID: <20131210013151.6caff6bf@TOMWIJ-GENTOO> (raw)
In-Reply-To: <21157.60822.905475.532655@a1i15.kph.uni-mainz.de>
[-- Attachment #1: Type: text/plain, Size: 2904 bytes --]
On Mon, 9 Dec 2013 17:19:34 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:
> >>>>> On Mon, 9 Dec 2013, Rich Freeman wrote:
>
> > If you think that B isn't the empty set, it is trivial for you to
> > demonstrate that this is the case. Simply give me a single example
> > of a situation where:
> > 1. It makes sense for a dep to use a new slot.
> > 2. It makes sense for all of its reverse deps to automatically use
> > the new slot without any further intervention by the individual
> > reverse dep maintainers.
>
> app-editors/emacs, to start with.
>
> If you go through the list of about 400 packages that have more than
> one slot (out of 17000 packages in the portage tree), I'm sure you'll
> find many more that fall in B. On first glance, only a minor part of
> these 400 seem to be libraries.
It is surprising that there are only ~400 packages that have multiple
slots available in the Portage tree; trying to reproduce this, I get a
similar number. Out of a ~350 total, ~75 contain "libs/", ~100 contain
"dev-java/" (almost a third); there's are some ruby and haskell libs
too. These groups are almost all libraries, so it somewhat fifty-fifty.
Note how Java packages already have a project policy to explicitly
specify slots on dependencies; as the eclass functionality relies on
that. As a consequence, it is easy to add a new slot to them. For the
Java herd it makes total sense to use explicit slots that way.
With new version bumps to reverse dependencies of dev-java libraries;
it is interesting to note that as time goes by, you will eventually
need to depend on the newer slot instead as upstream upgrades its
support for that dev-java library; dropping support for the old version.
But that's just a third and not necessarily representable, it can
however show how it works in practice.
Libraries' slot usage is harder to tell and needs a more thorough look
as to how these are done. It's easier to tell by someone whom has more
experience with how these libraries are versioned, seeing that most of
these are media-libs and x11-libs I'll try asking the relevant herds.
For applications (or should we say "all the rest") I think we need to
look at which kind of packages these are and what the slots mean.
For example, there are ~14 kernel sources that have multiple slots,
which are as far as I know not used as dependencies; it just serves
quite handy for the user to add it to the world file. There is also
www-client/google-chrome and sys-boot/grub, those are packages where
slots are meant for the user and not for reverse dependencies.
What do you think? Does someone have a different view? Please share. :)
--
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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-12-10 0:33 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-08 16:54 [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead? Tom Wijsman
2013-12-08 23:57 ` Patrick Lauer
2013-12-09 0:12 ` Tom Wijsman
2013-12-09 0:21 ` Rich Freeman
2013-12-09 6:52 ` Sergey Popov
2013-12-09 10:55 ` Tom Wijsman
2013-12-09 16:06 ` Rich Freeman
2013-12-09 16:19 ` Ulrich Mueller
2013-12-10 0:31 ` Tom Wijsman [this message]
2013-12-10 8:11 ` [gentoo-dev] " Martin Vaeth
2013-12-10 8:24 ` Ulrich Mueller
-- strict thread matches above, loose matches on Subject: below --
2013-12-08 16:56 [gentoo-dev] " Tom Wijsman
2013-12-08 17:16 ` Michał Górny
2013-12-08 17:19 ` Andreas K. Huettel
2013-12-08 17:26 ` Pacho Ramos
2013-12-08 17:46 ` Tom Wijsman
2013-12-08 18:56 ` Rich Freeman
2013-12-08 19:14 ` Ulrich Mueller
2013-12-08 19:39 ` Rich Freeman
2013-12-08 19:48 ` Ciaran McCreesh
2013-12-08 20:01 ` Ulrich Mueller
2013-12-08 20:17 ` Rich Freeman
2013-12-09 2:37 ` heroxbd
2013-12-09 2:55 ` Rich Freeman
2013-12-09 3:19 ` heroxbd
2013-12-08 20:21 ` Tom Wijsman
2013-12-08 20:25 ` Ciaran McCreesh
2013-12-10 21:06 ` Ian Stakenvicius
2013-12-10 23:35 ` Tom Wijsman
2013-12-08 20:04 ` Tom Wijsman
2013-12-08 20:21 ` Ulrich Mueller
2013-12-08 20:26 ` Ciaran McCreesh
2013-12-08 20:31 ` Ulrich Mueller
2013-12-08 21:54 ` Michał Górny
2013-12-08 22:02 ` Ciaran McCreesh
2013-12-08 20:28 ` Tom Wijsman
2013-12-08 20:30 ` Tom Wijsman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131210013151.6caff6bf@TOMWIJ-GENTOO \
--to=tomwij@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
--cc=ulm@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox