diff options
author | jnqnfe <jnqnfe@gmail.com> | 2015-01-18 20:39:36 +0000 |
---|---|---|
committer | Raphaƫl Hertzog <hertzog@debian.org> | 2020-03-13 13:56:21 +0000 |
commit | a6cc72bf6d2c27c8f10546085ed6a6a295b248cc (patch) | |
tree | 6c1e0713c5b858f810583b3e5c7c141f2414a95b /scripts/build/binary_loopback_cfg | |
parent | c54cc2c497977d5234a8ea6eb39deb09f0286546 (diff) | |
download | vyos-live-build-a6cc72bf6d2c27c8f10546085ed6a6a295b248cc.tar.gz vyos-live-build-a6cc72bf6d2c27c8f10546085ed6a6a295b248cc.zip |
strip useless multi-arch separate directory stuff
(part of never completed side-by-side multi archi support)
Several scripts make a call to a function called Check_multiarchitectures,
the purpose of which is to adjust the target directory that certain 'live'
and 'install' files are located in. The idea is that a script sets up
'DESTDIR', 'DESTDIR_LIVE' and 'DESTDIR_INSTALL' as appropriate and then
the script appends a suitable arch dependant postfix to the directory
name, depending upon the arch currently being targetted. This would allow
the script to be run multiple times, each for a different architecture.
This is a part of an implementation of allowing multiple architectures to
sit side by side within the same live image, selectable from the
bootloader menus. (As opposed to multiple architectures mixed within the
same userland).
This is evidently the case both from the fact that:
1) The arch specific postfix chosen in that function depends on a var
called LB_CURRENT_ARCHITECTURE, which is never set. In fact going
back through the git history to the introduction of the function in
0d5ff4ca7596790f853cf637e0fe225cad810a76, the var (even considering
var name changes) has never been set by anything. So effectively the
call to the function has been entirely redundant all this time.
2) The major build stages do not perform multiple executions of substages
per arch. Thus from this perspective it seems that the support was
never fully implemented.
3) If any doubt remained, there is an old branch called 'tmp-multiarch'
which has a couple of commits making progress with completing support,
such as implementing the above missing pieces.
The above mentioned branch is 10 years old and can be considered abandoned.
It is not clear whether the original author ever intended to complete and
merge this; nor is it at all clear at what stage of completion it was at.
At any rate, imo it is not at all particularly useful to have extra code
and complexity in order to be able to cram multiple environments side by
side in one image, not when CDs/DVDs and even to some extent USB pen drives
are so cheap. And who really needs more than one environment so
desperately on just one such medium.
If this was not enough to justify removal, then there is also the fact that
the support that was implemented has become completely broken over the
years with scripts diverging in terms of the variable names the function
modifies such that they are incompatible with it.
A quick assessment of the state of this latter aspect:
good:
- grub-legacy uses the correct var names so is fine
- memtest similarly good
- installer_debian-installer looks okay
questionable:
- binary_linux-image uses the correct vars but might not select the
right kernel and initrd files to copy (seems to copy all)
bad:
- grub-pc is making a redundant call, after functionality was moved
to the loopback script
- loopback is using the wrong vars (INITFS instead of DESTDIR +
DESTDIR_INSTALL + DESTDIR_LIVE), plus is doing its own amd64+i686
thing anyway, so the function call would achieve nothing anyway.
- syslinux is also using the wrong var names so would not work with
it and is not even making the necessary function call. Also the
install paths are fixed in the hard coded cfg files anyway so this
would need addressing with placeholders and sed replacement, but
then it is not entirely clear how things should work with respect
to install entries and multi-arch anyway, are we having multiple
copies of the installer, one for each target arch and then multiple
copies of the install menus, perhaps under different submenus?
So, this removes the artefacts of this never completed feature.
Gbp-Dch: Short
Diffstat (limited to 'scripts/build/binary_loopback_cfg')
-rwxr-xr-x | scripts/build/binary_loopback_cfg | 2 |
1 files changed, 0 insertions, 2 deletions
diff --git a/scripts/build/binary_loopback_cfg b/scripts/build/binary_loopback_cfg index 13e6d1ba9..63a9363a5 100755 --- a/scripts/build/binary_loopback_cfg +++ b/scripts/build/binary_loopback_cfg @@ -151,8 +151,6 @@ case "${LB_INITRAMFS}" in ;; esac -Check_multiarchitectures - # Setting boot parameters if [ "${LB_UNION_FILESYSTEM}" != "overlay" ] then |