[PATCH] avahi-systemd: drop postrm, use prerm instead

[PATCH] avahi-systemd: drop postrm, use prerm instead

[Andreas Oberritter]

* 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(-)

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
 }
 
-- 
1.7.9.5

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Koen Kooi]

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.

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Andreas Oberritter]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Koen Kooi]

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.

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Andreas Oberritter]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Enrico Scholz]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Andreas Oberritter]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Enrico Scholz]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Andreas Oberritter]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Enrico Scholz]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Andreas Oberritter]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Koen Kooi]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Enrico Scholz]

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

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Koen Kooi]

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.

Re: [PATCH] avahi-systemd: drop postrm, use prerm instead

[Enrico Scholz]

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