[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.

>>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.


Reply to: