On Jul 05, Cyril Brulebois <kibi@debian.org> wrote:
> > + case $ARCH in
> > + hurd-*) return 0 ;;
> > + amd64) link_dir="lib32 lib64 libx32" ;;
[...]
> I don't think having to play catch up with src:glibc is a good idea.
> Can't that be determined automatically instead of hardcoding this
> mapping?
I double checked with the glibc people: this could be done with gcc
-print-multi-lib, but I do not think that depending on gcc is an option
(also: foreign deboostrap).
> Besides, this code means an unknown architecture doesn't get merged
> /usr support. Is that intended/reasonable?
This would be a (small) problem only for new architectures with multilib
libraries, and I do not expect that we will have any more of these.
E.g. you can see that arm64 is not in the list since it does not use
/lib64 for multilib, but only multiarch.
Also, this would not be a big deal anyway because these extra links are
only needed to install multilib libraries, so if they will be needed at
development time for a new architecture they can easily be created
manually before installing the multilib libc package.
Also again, these links are only an interim workaround to support
merged-/usr systems without rebuilding the library packages: I expect
that in the future nobody would bother installing non-merged systems, so
if we can drop support for that then we can just build the multilib libc
packages to create the /lib64 symlinks themselves when installed.
> > first_stage_install () {
> > + case $SUITE in
> > + etch|etch-m68k|jessie|lenny|squeeze|wheezy) ;;
> > + oldstable|stable) ;;
> > + *) setup_merged_usr ;;
> This means “debootstrap stable” on stretch once it's released is going
> to lead to different results compared to “debootstrap stretch”.
I know, but I expected that at some point close to the next release the
"stable" keyword would be moved. Or is there a better approach?
--
ciao,
Marco
Attachment:
signature.asc
Description: PGP signature