On 31 October 2017 at 05:39, Kent Fredric <kentfred...@gmail.com> wrote: > > On 31 October 2017 at 15:54, David Golden <x...@xdg.me> wrote: > > On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis <pagalt...@gmx.de> > > wrote: > >> > >> > - Per the "explicit user confirmation", I think an explicit opt-in > >> > must be present, not merely checking for overwriting via hashing. > >> > >> I don’t think so, and think it’s fine to not require it. But you didn’t > >> state a reason why you think that so I don’t know whether I disagree > >> with you. > > > > > > Even if Peter's mechanism is in the spirit of the operating model, I would > > prefer the higher standard of "explicit confirmation" as the operating model > > call for. > > > > If you need a rationale -- practically speaking -- consider this scenario: > > > > 1. User without DBIC or DBIC::Boring installs some module Foo that depends > > on DBIC::Boring; DBIC::Boring gets silently installed. > > 2. User installs some module Bar that depends on DBIC; because DBIC doesn't > > check for conflicts with DBIC::Boring, it silently overwrites it. > > 3. Foo is now broken. User doesn't know why. > > > > Whereas if in #1, the user had to opt into DBIC::Boring, then they would be > > accepting the risk of future breakage from DBIC conflicts. > > I would expect based on the stability goals of DBIC::Boring, that this > would mean the same kinds of breakages would be present for anyone who > simply upgraded from an older version of DBIC to a newer version of > DBIC > > And subsequently, that module Foo is broken with new version of DBIC *anyway* > > Which means there is a logical problem in the ecosystem entirely > independent of the existence of DBIC::Boring
I disagree for several reasons. Firstly, you *assume* that due to DBIC::Boring's goals, DBIC will break by upgrading. DBIC might break future versions and might not. This is an assumption on your behalf and ignored the problem itself. Additionally, this assumes that DBIC::Boring's goals (even if pursued wholeheartedly and contain absolutely zero mistakes) would be the aim (and success) of any other Alt::*, thus dismissing David's general point, beyond DBIC::Boring. David gave a plausible situation in which package Foo could break due to unknowingly depending on Alt::Bar instead of Bar, wherein Bar might overwrite Alt::Bar. If you keep your position and assumptions on DBIC or DBIC::Boring aside, this problem is quite clear. There is an inherent problem for a user that does not explicitly know every distribution in their application's chain of dependencies. Honestly, the only ways I can think of (off-hand) is either 1) explicitly indicating "Yup, I know this. I'm okay with it. I'll take care of it if it breaks," or 2) A mechanism that detects it and reinstates Alt::Bar at the end; or 3) Bar knowing about Alt::Bar (and Alt::Bar::ButBetter) and not overwrite them. The last is unlikely, the first is more straightforward, and the second a long-term (but perhaps fragile) possibility. You cannot dismiss this case, only figure out how to ease it.
