[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Conflict/dependency granularity

> Bill Mitchell writes:
> >In this particular example, the ls program could no doubt go
> >in /usr/local/bin just as well (though there might be a config
> >file which needs to go in /etc), but there are probably other
> >examples which need to go into /usr/bin.  A cooperating
> >system of programs, possibly, which have it hardcoded
> >to look for one another in /usr/bin.
> But such a system would have problems under any other operating system
> and should still be fixed.  There's only so far one can go in terms of
> working around other people's bugs.

Where's the bug here?  And by whose standards is it a bug?
(I should check the FSSTND before I ask that question, to see if
 it reserves /bin, /usr/bin, and so forth for the distribution
 provider, but my copy is at home.  I don't think it does)

> >Perhaps I wasn't clear.  I wasn't proposing that current dependency
> >schemes be replaced with file dependencies.  I was saying that
> >the ability to specify file dependencies might also be useful in
> >some cases.
> I understood exactly what you meant.  My point was that there may be
> areas where file dependencies are not sufficient.

yup.  I think I said they wouldn't be a panacea.  I suggested this
because:  (1) I'm not convinced that Package dependencies and/or Virtual
dependencies are panacea(e?, s?) either; (2) given that there's no
panacea, a number of alternative means of specifying dependencies, each
probably covering holes which the some of others leave uncovered
might be a viable approach; (3) I imagine they'd be easy to do
(letting implementation concerns creep in, when I shouldn't do that)
(the code to parse dependency specs is already written -- all that
should be necessary would be to extend the control file syntax to
distinguish File dependencies from Package and Virtual dependencies,
and check for the specified files).

Reply to: