[ Adding kfreebsd and hurd porters to the loop. ]
Cyril Brulebois <kibi@debian.org> (2016-07-05):
> Marco d'Itri <md@linux.it> (2016-01-08):
> > +# Find out where the runtime dynamic linker and the shared libraries
> > +# can be installed on each architecture: native, multilib and multiarch.
> > +# This data can be verified by checking the files in the debian/sysdeps/
> > +# directory of the glibc package.
> > +#
> > +# This function must be updated to support any new architecture which
> > +# either installs the RTLD in a directory different from /lib or builds
> > +# multilib library packages.
> > +setup_merged_usr() {
> > + if [ "$MERGED_USR" = "no" ]; then return 0; fi
> > +
> > + local link_dir
> > + case $ARCH in
> > + hurd-*) return 0 ;;
hurd porters, is that OK?
kfreebsd porters, what should we have here for your archs?
For those wondering (and AFAICT) it seems the only issue here is how to
handle multilib, since multiarch is “hidden” below usr/lib (in
usr/lib/<triplet> subdirectories).
> > + amd64) link_dir="lib32 lib64 libx32" ;;
> > + i386) link_dir="lib64 libx32" ;;
> > + mips|mipsel)
> > + link_dir="lib32 lib64" ;;
> > + mips64*|mipsn32*)
> > + link_dir="lib32 lib64 libo32" ;;
> > + powerpc) link_dir="lib64" ;;
> > + ppc64) link_dir="lib32 lib64" ;;
> > + ppc64el) link_dir="lib64" ;;
> > + s390x) link_dir="lib32" ;;
> > + sparc) link_dir="lib64" ;;
> > + sparc64) link_dir="lib32 lib64" ;;
> > + x32) link_dir="lib32 lib64 libx32" ;;
> > + esac
> > + link_dir="bin sbin lib $link_dir"
> > +
> > + local dir
> > + for dir in $link_dir; do
> > + ln -s usr/$dir $TARGET/$dir
> > + mkdir -p $TARGET/usr/$dir
> > + done
> > +}
> > +
>
> 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?
Just checked with a regular porter, it doesn't seem crazy to expect
porters to come up with an extra patch for d-i/debootstrap support once
they're done bootstrapping their port. So, that addresses my initial
concern.
> Besides, this code means an unknown architecture doesn't get merged
> /usr support. Is that intended/reasonable?
Actually, this means an architecture which isn't listed doesn't get
extra paths, and /lib might be enough for some ports, e.g. arm64.
It would seem a better idea to list all ports explicitly though.
> > 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”.
That part remains to be fixed.
KiBi.
Attachment:
signature.asc
Description: Digital signature