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 19:21:08 -0500 [thread overview]
Message-ID: <CAGfcS_=Dk17xsTwYC8_DO+BSUOMhEXkdDzG3kaz+MEgDk8XcOg@mail.gmail.com> (raw)
In-Reply-To: <52A5076E.4070109@gentoo.org>
On Sun, Dec 8, 2013 at 6:57 PM, Patrick Lauer <patrick@gentoo.org> wrote:
> On 12/09/2013 12:54 AM, Tom Wijsman wrote:
>>
>> One thing that directly comes to mind is that dependencies that have no
>> SLOT="0" ebuild present would need us to manually specify a specific
>> SLOT; given that this is a not so common situation, the amount of
>> commits needed here is low.
>
> And now you make updating a lot more fun, because slotted packages need
> to be explicitly changed if there's a new slot happening. Just to hide
> your own laziness.
Frankly, your tone is rude here. Don't personalize things. The goal
is to eliminate non-value-added work. If a change makes work for
others that should be pointed out. If a change saves somebody time,
that isn't "laziness." Work isn't a virtue - accomplishing something
is. Discuss the merits of the proposal, and don't debate the morals
of the person making the proposal.
Second, I'm not sure exactly what you're trying to say here. Slotted
packages don't need to be changed under the proposed approach any more
than they otherwise would. If you have SLOT=0 of libfoo and want to
introduce SLOT=1 it is the same amount of work for the libfoo
maintainer either way. The only difference is that if half the tree
depends on libfoo and breaks with libfoo:1 then there are a bazillion
failures all the sudden.
If you meant that packages that depend on slotted packages need to be
changed, then that isn't really correct either. If a package depends
on libfoo:0 instead of libfoo:*, it will work just fine when libfoo:1
is introduced - it will just continue to pull in libfoo:0. Then over
time maintainers can test and add an || dep for libfoo:1 and the
package will work with either.
The status quo requires the libfoo maintainers to do a ton of work to
get everybody to change their deps before introducing a new slot.
Either that or they do what everybody else apparently does and not use
slots at all, just creating libfoo2. Well, if you can't reliably
create new slots for dependencies, then what is the point of having a
syntax for slot dependencies in the first place?
On IRC there was some discussion and it may make sense to not make the
default :0 (or :0=), but rather to just not have any default in a
future EAPI - every single dependency line would therefore contain a
slot. I'm not convinced wildcards should even be allowed - the whole
point of introducing new slots is that the new version may not be
compatible, so how can you say in advance that any slot is acceptable?
If the new library is API-compatible then it should just be a new
subslot in the same slot, and if it is ABI-compatible then it should
be in the same subslot. The whole point of subslots is to handle
packages that have API breaks, and I don't see how wildcards against
future versions not even written yet can be appropriate there. The
only thing that it does is saves maintainers the trouble of looking up
what slots the package was actually tested against, which sounds a bit
like a certain word that starts with l... :)
Rich
next prev parent reply other threads:[~2013-12-09 0:21 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 [this message]
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
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='CAGfcS_=Dk17xsTwYC8_DO+BSUOMhEXkdDzG3kaz+MEgDk8XcOg@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