On Tue, Jul 05, 2005 at 04:56:34PM -0400, David Wood wrote: > Why bother making it hard when you can just make it easy and link the > whole directory?
You can't make a link to a child of yourself since then the child has no parent dir to beling to if the parent isn't a directory. it would work if you did this: /usr/lib -> /.crap/usr/lib/i386-linux Then the parent isn't /usr/lib and hence you can make /usr/lib whatever you want. Just doesn't seem that nice to me. But it doesn't work with: /usr/lib -> /usr/lib/i386-linux Since in that case you either have to create the directories /usr/lib/i386-linux at which point you can't make /usr/lib a symlink since there already exists a dir with that name, and if you create the symlink /usr/lib pointing to /usr/lib/i386-linux first (with the target obviously nonexistant) then you won't be able to make the directory since /usr/lib that it should go in doesn't point to a location that exists so you can't make a subdir in it. > I don't see a problem here. The case seems rare; when it happens the order > of the elements in PATH dictates preference, and aliases (or any other > mechanism) can be used to override. > > The common case is to deal with libraries for packages that aren't > available on both architectures anyway. But you need both versions of each library in case you have programs that only come for one or the other of the architectures that needs those libs. > This sounds like a good example of what work will be involved in reforming > packages to deal with the new standard. Probably you end up with those > share files in "common" noarch packages that are a dependency of the > arch-specific ones. In fact I think I've seen packages doing that already. That would work, but would require fixing some packages for sure. Len Sorensen -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]