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

Koen Kooi koen at dominion.thruhere.net
Mon May 21 12:06:48 UTC 2012


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 at 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




More information about the Openembedded-core mailing list