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.
>>Such conflicts still exist in DOS and Windows - it's just that there's
>>no standard mechanism for finding out about them.
>
>Probably. Are you offering that as an argument that we should
>leave the area unaddressed when we could address it? That is
>a decision point for us.
No, I'm pointing out that we already address the relationships between
software packages where DOS and Windows don't.
>>[...] file dependencies could still cause problems. How
>>do you depend on /usr/lib/gcc-lib/i486-debian-linux/2.6.3/libgcc.a,
>>for example? That version number is going to change one day
>>... perhaps likewise the 'i486', and even the 'linux' if there were a
>>Hurd-based Debian. In this example, a virtual package would win.
>
>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.
ttfn/rjk
Reply to: