Op 21 mei 2012, om 13:49 heeft Andreas Oberritter het volgende geschreven:
> On 21.05.2012 13:04, Enrico Scholz wrote: >> Andreas Oberritter <[email protected]> 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? > > Every recipe inheriting gconf.bbclass, gtk-icon-cache.bbclass, > kernel.bbclass, module.bbclass or libc-package.bbclass, for example. You > can use git grep '$D' to find more candidates. > >> 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. > > Considering that in the meantime my similar patch [1] to systemd.bbclass > got merged into meta-oe by Koen, who initially was against it, I guess > this patch can finally get merged now, too. Crap, I missed the $D part, that's going to get reverted _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
