On Mon, 5 Aug 2013 17:36:49 +0100 Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote:
> On Mon, 5 Aug 2013 12:22:32 -0400 > Alexis Ballier <aball...@gentoo.org> wrote: > > On Mon, 5 Aug 2013 17:13:49 +0100 > > Ciaran McCreesh <ciaran.mccre...@googlemail.com> wrote: > > > On Tue, 06 Aug 2013 02:03:28 +1000 > > > Michael Palimaka <kensing...@gentoo.org> wrote: > > > > > How often does this situation even come up? If 9/10 times the > > > > > libraries are set up as maintainers expect them to be, it is > > > > > probably better to deal with the odd unnecessary rebuild until > > > > > somebody spots it, rather than going without support for slot > > > > > operator deps. > > > > > > > > With respect, "good enough" is not a very high standard to aim > > > > for. In my opinion, adding unnecessary subslot dependencies is > > > > no different to adding overly-wide dependencies. > > > > > > There's a world of difference between a horrible breakage and an > > > occasional unnecessary compile. If users are concerned about how > > > they spend their CPU time, they're using the wrong distribution. > > > > there is something wrong in the way its done if there are > > 'occasional unnecessary compiles' > > Not really. There's a tradeoff between dependencies that are > occasionally too strict, and dependencies that are horribly > complicated (see "subslot dictionaries"). having a way to express 'my subslot is the one of my provider' doesnt seem overly complicated > Gentoo already favours lots of unnecessary recompiling over additional > complexity. For example, for many revbumps, it would be possible to > only rebuild a small part of the package and replace a few files > rather than the whole thing. But writing ebuilds capable of doing so > would involve more developer work, and would be more prone to > screwups, so such a feature isn't offered. > > So all this fuss over "unnecessary compiles" is misplaced. Gentoo > simply isn't the right distribution to use if minimising compile time > is a goal. two wrongs do not make one right... esp. when the 'wrong' at hand can be easily avoided... > > 'horrible breakage' is mitigated by preserve-libs and running > > @preserved-rebuild as soon as possible has the same end result > > avoiding useless rebuilds. > > But preserve-libs introduces breakages and security holes. The point > of slot operator dependencies is to replace that with a reliable > feature that doesn't rely upon guesswork and voodoo. not more than subslots, per pms: The sub-slot is used to represent cases in which an upgrade to a new version of a package with a different sub-slot may require dependent packages to be rebuilt. so, per spec, it isnt reliable either since the spec does not enforce rebuilds as soon as possible, heck, it doesnt even enforces rebuilds... (may vs must + when) in the present example, the spec allows the following scenario leaving your system in a broken state and triggering useless rebuilds: - update virtual/jpeg with new subslot - rebuild all dependent packages - update provider of virtual/jpeg
