El 21/12/17 a las 14:11, Raphael Hertzog escribió: > Hi, > > On Sat, 16 Dec 2017, adrian15 wrote: >> Now using: >> >> --linux-flavours="amd64:amd64 686" >> >> in a i386 system does install amd64 kernel from amd64 architecture in a >> transparent manner. >> >> Please tell me if there's something to be polished so that it's accepted >> upstream. > > Your patch does nothing except dropping the ":amd64" suffix. You could > just as well not use the suffix and use your system where you manually > enabled the foreign architecture. > > I would have expected your patch to somehow add the foreign architecture > to the build chroot and figure it out from there. > > As it stands, I don't see the point of this patch. > > Cheers,
I wanted to spare you the long explanation but here it goes. 1) live-build already enables the foreign architecture in linux flavour associated packages https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/chroot_install-packages?id=acafe6618bfb7a9f7525e723e13ade2956e10b4f#n45 That: packages.foreign-architectures file gets created at: https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/chroot_package-lists?id=acafe6618bfb7a9f7525e723e13ade2956e10b4f#n80 which it's reading: packages.chroot file. packages.root file is being feed up with the linux flavour packages in: https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/chroot_linux-image?id=acafe6618bfb7a9f7525e723e13ade2956e10b4f#n51 2) My first implementation of this patch tried not to invent a new package variable (which would keep the :amd64 package suffix) but to invent a new filename variable so that further code regarding installing different linux kernel filenames did not fail later in the code. I mean: DEFAULT_KERNEL="$(basename chroot/boot/vmlinuz-*${DEFAULT_FLAVOUR})" would have translated to: DEFAULT_KERNEL="$(basename chroot/boot/vmlinuz-*amd64:amd64)" and there is no such installed files with those filenames. You can check it here: https://github.com/rescatux/live-build/commit/25bbc377a2e9ca67240f7a396f53637426ba4eb6 I discarded myself this implementation because it modifies too many lines (Occam's razor reference) and seems too much of an artificial fix. 3) So I dropped that implementation of the patch and searched for something more elegant. A patch that modified the least possible lines of the live-build code and I finally found out how... with this new package based variable that would only have to be used in one specific place. And that's the patch I submitted here in the first place. Do you prefer my discarded implementation? The one I sent initially? Or is it a better way of approaching this problem? Thank you for your feedback. adrian15 -- Support free software. Donate to Super Grub Disk. Apoya el software libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/