James Falkner wrote: > > > Dave Miner wrote: >> 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, > > It is the default, *if* user B acknowledges the existence of user A's > dependence. >
That's our critical point of disagreement. I don't think B should have to acknowledge it, it just introduces a manual action that seems unnecessary. > The problem is that when user A installs a package that depends on B's > package, B has no knowledge of this installation. So when B goes to > remove their package, the tool does not know that A depends on it, > unless 1) it does an exhaustive search of the entire filesystem, > including network shares, starting at /, or 2) B provides a list > of domains that potentially contain dependent software, or 3) > both users install their software into a centralized registry or > other repository, replete with with user administration and > authorization capabilities, and can track and maintain dependency > relationships across users/nodes/OSs/etc. > How about another alternative: 4) Each user's domains are registered centrally, automatically, and the packaging system will automatically search all known domains and warn when an action may create a problem > While I agree that the latter is beneficial and I think would give > you the administrative control you desire, I feel that this proposal > does not preclude that in the future (in fact it takes a baby > step toward it, by tracking cross-user dependencies in a scalable > manner), while at the same time meeting many of the needs of customers > who have been asking for this ability for quite some time. > I don't think it goes quite a baby step, because it's still up to each user to construct a correct universe of possible dependent domains and manage it over time, so unless you have exceptionally well-behaved users, it just won't happen. Why wouldn't/couldn't we do that for them? Really, I don't believe I'm asking for much. Dave
