From: Rich Freeman <rich0@gentoo.org>
To: gentoo-dev <gentoo-dev@lists.gentoo.org>
Subject: Re: [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes?
Date: Mon, 16 Jun 2014 06:54:09 -0400 [thread overview]
Message-ID: <CAGfcS_m=zK_N3bCTk=GF3CAh+SZCP=Hj5xvwDJsft5MqADyc9w@mail.gmail.com> (raw)
In-Reply-To: <1402912078.2466.8.camel@belkin5>
On Mon, Jun 16, 2014 at 5:47 AM, Pacho Ramos <pacho@gentoo.org> wrote:
> El sáb, 14-06-2014 a las 12:50 -0400, Alexandre Rostovtsev escribió:
> [...]
>> A solution to unnecessary rebuilds in these situations, as well as for
>> case (1), might be in the form of subslots as a key:value list, with
>> different users subscribing to be rebuilt for specific keys.
>
> I guess https://bugs.gentoo.org/show_bug.cgi?id=462138 will interest you
> too :)
While the pain-vs-gain argument in that bug makes some sense, I don't
buy the argument that the purpose of subslots is to force necessary
rebuilds vs prevent unnecessary ones. Those are really equivalent,
since a crude algorithm would be to simply rebuild every package
anytime any package changes. Subslots prevent you from having to
rebuild unnecessary packages by identifying the packages that actually
need to be rebuilt.
The fact that we already have maintainers setting sublots on virtuals
suggests to me that this feature should be given more consideration.
Given a choice of a rats-nest of virtuals that need to be updated
anytime there is a bump and mapped to a main subslot that doesn't mean
anything or just having a dictionary on the packages that need it, the
latter seems simpler for everybody. In the case where a single
subslot is needed the whole thing reduces to EAPI5.
Rich
next prev parent reply other threads:[~2014-06-16 10:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-14 14:41 [gentoo-dev] Subslots: should they be bumped like SONAME or on any ABI changes? Michał Górny
2014-06-14 15:13 ` Ciaran McCreesh
2014-06-14 15:32 ` hasufell
2014-06-14 15:45 ` Ciaran McCreesh
2014-06-14 16:04 ` Georg Rudoy
2014-06-14 16:16 ` hasufell
2014-06-14 16:19 ` Ciaran McCreesh
2014-06-14 16:25 ` hasufell
2014-06-14 15:50 ` Alexandre Rostovtsev
2014-06-14 15:56 ` Ciaran McCreesh
2014-06-14 16:17 ` Alexandre Rostovtsev
2014-06-14 16:31 ` Ciaran McCreesh
2014-06-14 16:35 ` Alexandre Rostovtsev
2014-06-14 20:00 ` Rich Freeman
2014-06-14 23:41 ` Patrick Lauer
2014-06-14 16:05 ` Ian Stakenvicius
2014-06-14 16:10 ` [gentoo-dev] " Michael Palimaka
2014-06-14 16:23 ` [gentoo-dev] " hasufell
2014-06-14 16:50 ` Alexandre Rostovtsev
2014-06-14 16:57 ` Alexandre Rostovtsev
2014-06-14 17:13 ` [gentoo-dev] " Michael Palimaka
2014-06-16 9:47 ` [gentoo-dev] " Pacho Ramos
2014-06-16 10:54 ` Rich Freeman [this message]
2014-06-15 19:13 ` Matt Turner
2014-06-16 9:44 ` Pacho Ramos
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_m=zK_N3bCTk=GF3CAh+SZCP=Hj5xvwDJsft5MqADyc9w@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