Re: multiarch/bi-arch status (ETA) question
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
Reply to: