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: