fosslinux / live-bootstrap

Use of a Linux initramfs to fully automate the bootstrapping process
291 stars 26 forks source link

src_install() shouldn't touch the live system #377

Closed Googulator closed 5 months ago

Googulator commented 6 months ago

The following packages all touch the live system (adding, deleting or modifying files outside $DESTDIR) in their src_install:

All of these alterations to the live system will fail to be reproduced when these packages are installed from preseeded tarballs, rather than built in place.

If any of these changes is genuinely necessary, then we need to implement src_apply override support in helpers.sh, and move the relevant code there, so the proper FS changes will be made regardless of whether we're building or installing from preseed.

stikonas commented 6 months ago

Well, we need some way to remove old files. Normally distros have install manifests to keep track of files to be removed when installing upgrades.

Googulator commented 6 months ago

That makes sense, whenever such cleanup is actually required, and is not merely a holdover from before live-bootstrap had the package system in place. However, it should be done in the actual package install path (which is src_apply(), not src_install(), which is actually part of package generation).

Unfortunately src_apply() isn't currently overrideable - to fix that, we need to rename the current implementation to default_srcapply(), allow it to be overridden in package scripts as needed, and make sure that the package script is loaded also when installing a prebuilt package (which we currently don't do). To clear up confusion, it may also make sense to rename (default)srcinstall() to (default)src_package(), to make it clearer what it actually does.

For the rare occasion where e.g. "make install" to fakeroot depends on some file not yet existing on the live system, and such misbehavior can't just be patched out for some reason, my preferred solution would be to back up the conflicting files, generate the packages, and finally restore the affected files. If desired, the same files can then be removed for good in that package's src_apply(), when that package is installed. This is also a prerequisite if we ever want to build packages that we don't immediately want to install to the live system.

fosslinux commented 6 months ago

To me, what makes the most sense here is adding some kind of uninstall function; that reads a filelist (probably generated from a tarball in the repo), and removes said files.

I'd prefer actually having removal of old files in steps/manifest now, because removal of old files isn't really tied to any specific package. Could have two forms, one used for generated packages and one for pre-kaem, eg

uninstall: perl-5.6.2 # removes the old package perl 5.6.2
uninstall: /usr/bin/lex # removes the lex binary
Googulator commented 6 months ago

Maybe that can be implemented also as improve steps (e.g. "improve: cleanup-old-perl").