From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead?
Date: Sun, 8 Dec 2013 15:17:46 -0500 [thread overview]
Message-ID: <CAGfcS_nwTc3AYPQ8cmGR=xQCtfQfru2NhBC8Wtpvui-BARqB5A@mail.gmail.com> (raw)
In-Reply-To: <21156.53244.886349.924357@a1i15.kph.uni-mainz.de>
On Sun, Dec 8, 2013 at 3:01 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
> Our rules of slot/subslot dependencies and slot operators are just
> complicated enough, so I really would dislike complicating them even
> more by having an EAPI dependent default. In addition, from a package
> manager view there is nothing special at all about slot 0, so there's
> no reason to prefer it over other values.
I can see that argument, but what then? What should be the best
practice for a maintainer?
A new slot of a package (which doesn't exist today) may or may not
work with any ebuild in the system. Should it be considered a best
practice then to specify || deps with all slots that are known to work
in the tree? Or should we just trust to luck and consider it
acceptable for maintainers to add new slots of commonly-used libs and
users and downstream maintainers can deal with the resulting breakage?
Library maintainers don't seem to like dealing with that, so they just
stick new slots in an entirely new package, and then we end up with
all the || dependencies anyway and we make no use of the nice slot
syntax because it is prone to breakage.
It seems like the current way we handle slots for dependencies works
just fine until somebody actually tries to introduce a new slot for a
package, and then a whole pile of assumptions comes crashing down.
Rich
next prev parent reply other threads:[~2013-12-08 20:17 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-08 16:56 [gentoo-dev] Dependencies default to accept any slot value acceptable (:*), can we default to :0 instead? 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
2013-12-08 16:54 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
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='CAGfcS_nwTc3AYPQ8cmGR=xQCtfQfru2NhBC8Wtpvui-BARqB5A@mail.gmail.com' \
--to=rich0@gentoo.org \
--cc=gentoo-dev@lists.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