Re: multiarch/bi-arch status (ETA) question
Digesting about 8 things into a single response...
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
You only need dpkg support to utilize it. The design is such that the
debs shall remain compatible to older debian. You just don't get the
multiarch benefits. So apt/dpkg are not realy blocking issues to
porting stuff.
...
The plan is to add multiarch support step by step while having a
single arch system right up to the moment everything is ready. And
even after having single arch must be possible. People that want
pure64 should never be forced to install 32bit cruft as well and vice
versa.
This is the heart of what I'm saying... And hence my questions so far.
On Wed, 6 Jul 2005, Hugo Mills wrote:
They're not (directly) the way that the Debian multiarch is most
likely to go. Unfortunately, the relevant site seems to be down, but
take a look at [1], and possibly some of the other (Google cached)
files in [2].
Just out of curiosity; does anyone know what was wrong with the
way documented in:
http://www.linuxbase.org/futures/ideas/multiarch/
On Wed, 6 Jul 2005, Hugo Mills wrote:
If I may venture a little further, the idea that all of this must be done
in one giant atomic effort is apparently very popular... why?
Because you can't demonstrate that your modified packages are
actually going to work properly (and in fact, they won't, if you make
only the modifications you propose) without having a working
multiarch-aware packaging system to test them with.
Sure you can. Just test them.
It sounds like you want to maintain two sets of packages: one normal, one
fixed for multiarch. Is that really easier than just making the links,
updating your existing set of packages over time, and doing verification
on a pre-release multiarch systems with increasing aggressiveness until a
multiarch release?
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
Having the links can hide problems in other parts I would rather see
crash and burn during build than 2 years from now when symlinks are
removed.
How are they hidden unless you are not looking?
To test you just remove links, right?
The benefit being with the links in place you can start migrating
packages while continuing to use them.
On Wed, 6 Jul 2005, Goswin von Brederlow wrote:
That would look how?
The only one symlink solution is '/usr/bin/i386 -> .' and changes
nothing.
I see what you mean, but I still don't understand. It changes something; I
can then start to port existing packges, instead of having to keep two
sets.
On Wed, 6 Jul 2005, Lennart Sorensen wrote:
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.
Thank you (all) for the patient explanation. I knew there was something I
wasn't getting.
.crap would work; I agree it's not nice, but I'm thinking, your
alternative is maintaining and transitioning to a whole alternative set of
packages. Surely a solution that allows you to move the existing packages
gradually is the lesser evil?
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.
Something else ugly... Just curious, why would this break:
mkdir /usr
mkdir /usr/lib
ln -s /usr/lib /usr/lib/i386-linux
It's "recursive," but it appears functional...
Reply to: