| Submitter | Andreas Oberritter |
|---|---|
| Date | May 16, 2012, 4:55 p.m. |
| Message ID | <1337187331-4945-1-git-send-email-obi@opendreambox.org> |
| Download | mbox | patch |
| Permalink | /patch/27835/ |
| State | New |
| Headers | show |
Comments
Op 16 mei 2012, om 18:55 heeft Andreas Oberritter het volgende geschreven: > * Calling "systemctl disable" from postrm is too late and > causes the following error: > > | Failed to issue method call: No such file or directory > > * Fix indentation of prerm for resulting shell snippet. > * Messing with $D is not needed in *rm scripts. It very much is, you can offline remove scripts just like you can install them.
On 16.05.2012 19:17, Koen Kooi wrote: > > Op 16 mei 2012, om 18:55 heeft Andreas Oberritter het volgende geschreven: > >> * Calling "systemctl disable" from postrm is too late and >> causes the following error: >> >> | Failed to issue method call: No such file or directory >> >> * Fix indentation of prerm for resulting shell snippet. >> * Messing with $D is not needed in *rm scripts. > > It very much is, you can offline remove scripts just like you can install them. What's the use case for removing packages offline and where in OE is this used? Is the majority of prerm- and postrm-scripts prepared for that? Regards, Andreas
Op 16 mei 2012, om 20:38 heeft Andreas Oberritter het volgende geschreven: > On 16.05.2012 19:17, Koen Kooi wrote: >> >> Op 16 mei 2012, om 18:55 heeft Andreas Oberritter het volgende geschreven: >> >>> * Calling "systemctl disable" from postrm is too late and >>> causes the following error: >>> >>> | Failed to issue method call: No such file or directory >>> >>> * Fix indentation of prerm for resulting shell snippet. >>> * Messing with $D is not needed in *rm scripts. >> >> It very much is, you can offline remove scripts just like you can install them. > > What's the use case for removing packages offline e.g. BAD_RECOMMENDATIONS > and where in OE is > this used? Is the majority of prerm- and postrm-scripts prepared for that? Dunno if the majority is, but you're now actively making it worse.
On 16.05.2012 20:50, Koen Kooi wrote: > > Op 16 mei 2012, om 20:38 heeft Andreas Oberritter het volgende geschreven: > >> On 16.05.2012 19:17, Koen Kooi wrote: >>> >>> Op 16 mei 2012, om 18:55 heeft Andreas Oberritter het volgende geschreven: >>> >>>> * Calling "systemctl disable" from postrm is too late and >>>> causes the following error: >>>> >>>> | Failed to issue method call: No such file or directory >>>> >>>> * Fix indentation of prerm for resulting shell snippet. >>>> * Messing with $D is not needed in *rm scripts. >>> >>> It very much is, you can offline remove scripts just like you can install them. >> >> What's the use case for removing packages offline > > e.g. BAD_RECOMMENDATIONS Packages in BAD_RECOMMENDATIONS don't get installed. So there's no need for them to get removed. Do you know any real use case? >> and where in OE is >> this used? Is the majority of prerm- and postrm-scripts prepared for that? > > Dunno if the majority is, but you're now actively making it worse. I doubt it unless proven wrong. Actually there's only one line matching opkg-cl.*remove, which is a very special case: openembedded-core/meta/classes/rootfs_ipk.bbclass: opkg-cl ${IPKG_ARGS} --force-depends remove update-rc.d base-passwd || true Regards, Andreas P.S.: No line matches opkg-cl.*upgrade
Andreas Oberritter <obi-Le4rqY8tBtjh/77Yhslz0w@public.gmane.org> writes:
> What's the use case for removing packages offline
I am developing very much with NFS root filesystems (--> the temporary
image directory which is kept by IMAGE_KEEPROOTFS=1). Packaging operations
like install, remove or upgrade are common actions to test recipes and
applications.
Enrico
On 18.05.2012 17:06, Enrico Scholz wrote: > > > Andreas Oberritter <obi-Le4rqY8tBtjh/77Yhslz0w@public.gmane.org> writes: > >> What's the use case for removing packages offline > > I am developing very much with NFS root filesystems (--> the temporary > image directory which is kept by IMAGE_KEEPROOTFS=1). Packaging operations > like install, remove or upgrade are common actions to test recipes and > applications. Just to make sure we're talking about the same thing: Do you run opkg-cl on the build machine to remove or upgrade packages inside the target's NFS root? Regards, Andreas
Andreas Oberritter <obi@opendreambox.org> writes: >>> What's the use case for removing packages offline >> >> I am developing very much with NFS root filesystems (--> the temporary >> image directory which is kept by IMAGE_KEEPROOTFS=1). Packaging operations >> like install, remove or upgrade are common actions to test recipes and >> applications. > > Just to make sure we're talking about the same thing: Do you run > opkg-cl on the build machine to remove or upgrade packages inside the > target's NFS root? yes; I am working on the build machine. The NFS filesystem is mounted read-only on the target. Enrico
On 21.05.2012 11:18, Enrico Scholz wrote: > Andreas Oberritter <obi@opendreambox.org> writes: > >>>> What's the use case for removing packages offline >>> >>> I am developing very much with NFS root filesystems (--> the temporary >>> image directory which is kept by IMAGE_KEEPROOTFS=1). Packaging operations >>> like install, remove or upgrade are common actions to test recipes and >>> applications. >> >> Just to make sure we're talking about the same thing: Do you run >> opkg-cl on the build machine to remove or upgrade packages inside the >> target's NFS root? > > 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? How do you handle the majority of scripts that don't care about $D at all? I think your use case is unsupported and always will be. In contrast, packages having failing postinst scripts will re-run their scripts on the target on first boot. Regards, Andreas
Andreas Oberritter <obi@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
On 21.05.2012 13:04, Enrico Scholz wrote: > Andreas Oberritter <obi@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? 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. Regards, Andreas [1] http://git.openembedded.org/meta-openembedded/commit/?id=637cb7e3d2cfdc74d239a4257e6f3477aa17da4e
Op 21 mei 2012, om 13:49 heeft Andreas Oberritter het volgende geschreven: > On 21.05.2012 13:04, Enrico Scholz wrote: >> Andreas Oberritter <obi@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? > > 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
Koen Kooi <koen@dominion.thruhere.net> writes: >> 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 I think we can keep it when we enhance the systemctl script (systemd-systemctl-native) to ignore 'stop/start'. This will simplify the install scripts because the | if [ -z "$D" ]; then | systemctl stop ... | fi block can be replaced by a simple 'systemctl stop ...' Enrico
Op 21 mei 2012, om 14:13 heeft Enrico Scholz het volgende geschreven: > Koen Kooi <koen@dominion.thruhere.net> writes: > >>> 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 > > I think we can keep it when we enhance the systemctl script > (systemd-systemctl-native) to ignore 'stop/start'. That won't work where you don't the have OE tree at hand. Worst case: it will call the native systemctl and break the host distro.
Koen Kooi <koen@dominion.thruhere.net> writes: >>>> 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 >> >> I think we can keep it when we enhance the systemctl script >> (systemd-systemctl-native) to ignore 'stop/start'. > > That won't work where you don't the have OE tree at hand. Is this case really supported? Lot of scripts depend on encapsulation by 'pseudo' and/or special wrapper programs. E.g. 'update-alternatives' must be the tool of the OE tree; the host utility will be used which does not understand $OPKG_OFFLINE_ROOT. Else, systemd-systemctl-native is sysrooted by every package inheriting 'systemd.bbclass' and available in every OE tree. > Worst case: it will call the native systemctl and break the host > distro. This would also be the case for the already unwrapped | systemctl enable ....service But again... this is not a problem because a custom systemctl script is installed. Enrico
Patch
diff --git a/meta/recipes-connectivity/avahi/avahi.inc b/meta/recipes-connectivity/avahi/avahi.inc index 61ca25f..f84a81d 100644 --- a/meta/recipes-connectivity/avahi/avahi.inc +++ b/meta/recipes-connectivity/avahi/avahi.inc @@ -14,7 +14,7 @@ SECTION = "network" # python scripts are under GPLv2+ LICENSE = "GPLv2+ & LGPLv2.1+" -INC_PR = "r2" +INC_PR = "r3" DEPENDS = "expat libcap libdaemon dbus glib-2.0" @@ -163,12 +163,7 @@ pkg_postinst_avahi-systemd() { systemctl enable avahi-daemon.service } -pkg_postrm_avahi-systemd() { - # can't do this offline - if [ "x$D" != "x" ]; then - exit 1 - fi - - systemctl disable avahi-daemon.service +pkg_prerm_avahi-systemd() { +systemctl disable avahi-daemon.service }
* Calling "systemctl disable" from postrm is too late and causes the following error: | Failed to issue method call: No such file or directory * Fix indentation of prerm for resulting shell snippet. * Messing with $D is not needed in *rm scripts. Signed-off-by: Andreas Oberritter <obi@opendreambox.org> --- meta/recipes-connectivity/avahi/avahi.inc | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-)