Andreas Oberritter <o...@opendreambox.org> writes: >>>>> What's the use case for removing packages offline >> >> yes; I am working on the build machine. The NFS filesystem is mounted >> read-only on the target. > > How do you handle prerm and postrm scripts that fail because $D is > set?
Fortunately, there are very few packages where this failure is critical (--> package is not working). Important tasks like user creation, alternatives handling or systemctl calls take care about offline package management already. kernel modules are the only package class which might affect me and is not suited for offline installation/upgrades. But I can live with it because I develop the kernel at a separate location and call 'make modules_install INSTALL_MOD_PATH=<nfsroot>' there. > How do you handle the majority of scripts that don't care about $D at > all? Examples? pseudo does a good job for 'systemctl enable/disable' or update-alternatives operations, 'systemd.bbclass' wraps the 'systemctl stop/start'. Btw... your patch is correct about removal of $D. As written above, it is not needed for 'systemctl disable'. But I am against removal of offline capabilities because they are not needed in 80% of use cases. Enrico _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
