James Falkner wrote: > > > Dave Miner wrote: > >>>>>> I'm interested in some elaboration of the DOS concern. I can >>>>>> imagine some concerns, but I'd like to understand what you're >>>>>> specifically trying to prevent. >>>>> >>>>> The system must not depend in any way on software that it does not >>>>> own. >>>>> >>>> >>>> That doesn't answer my question in any way that is meaningful. What >>>> is the threat that we're attempting to design against? >>> >>> that the system has a dependency on a package in the users home >>> directory, or that user A's software depends on user B's. >>> >> >> I agree that the former is probably almost always undesirable, but I'm >> not so sure about the latter. But how do you really prevent it when >> you introduce something with the flexibility of the Domain-Path >> proposed here? And why shouldn't we be able to use Domain-Path for >> the root domain? There may be cases where it makes sense. So I'm >> still not sure what sort of denial we're really defending against. > > The user-to-user threat that would exist would be that rogue user A > installs > a package into ~A that depends on nice user B's package. When nice user > B goes to remove said package, they would get a failure, warning, or > interactive question about breaking some rogue user A's package. That > shouldn't happen unless nice user B wants it to happen, by putting > A into their search/dependency domain-path. >
Thanks for elaborating on what you meant. I'd of course buy not failing on DOS grounds, but I believe a warning/question is desirable as the default. If we're going to enable users to cooperate, let's do it well, not partially. Otherwise we're just allowing users to create unnecessarily fragile software stacks. Dave
