Fwd: [Rpm-maint] [PATCH] "%post -p /sbin/ldconfig" wrongly skipped

devzero2000 pinto.elia at gmail.com
Sun Apr 20 11:48:48 UTC 2008


---------- Forwarded message ----------
From: devzero2000 <pinto.elia at gmail.com>
Date: Sun, Apr 20, 2008 at 1:42 PM
Subject: Re: [Rpm-maint] [PATCH] "%post -p /sbin/ldconfig" wrongly skipped
To: Panu Matilainen <pmatilai at laiskiainen.org>


P.S. Did you send this question privately on purpose? Just for the record, I
> wont mind if you reply back to / cc rpm-maint list.
>

No Panu, just an error of my mail client. Thanks for the reply.





On Sun, Apr 20, 2008 at 8:41 AM, Panu Matilainen <pmatilai at laiskiainen.org>
wrote:

> On Sat, 19 Apr 2008, devzero2000 wrote:
>
>  So for resolving this problem it is necessary to look the "new" dkpg
> > trigger mechanism that rpm have from 1997 iirc ?  Ok probably the name are
> > similar but the function are different : i have to look at it in depth.
> >
>
> Looking at dpkg triggers is hardly "necessary", but when somebody has
> already put considerable effort to solving the same problem it'd be stupid
> not to look at what they've done.
>
> The dpkg triggers are not to be confused with rpm triggers although some
> similarities exist. If you look at the scrollkeeper example from the
> specification, scrollkeeper package puts a trigger (or a watch, if you wish)
> on /usr/share/omf/ directory: any package updating the contents of that
> directory will activate that particular trigger (to run
> scrollkeeper-update), but it'll run just once "when convenient" - convenient
> would be for example once the transaction has otherwise finished.
>
> I haven't yet read the dpkg trigger specification in enough detail to
> comment on the other forms, but the ide a of putting watches on files and
> directories to execute something just once certainly seems like a useful
> idea, rpm just needs some different terminology to avoid confusion with the
> existing but different trigger mechanism.
>
>  But if posttrans isn't perfect today but it can solve the issue
> > why dosn't resolve the erasure problem in first place ? In every case it
> > would be useful: a resolved problem is always an improvement.
> >
> > This  seems a reasonable question.
> >
>
> %posttrans, whether it runs for erased packages or not, is not the
> solution to this problem. While we are talking about things that get run
> most likely only after the transaction finishes, %posttrans != "anything
> post transaction", it has it's own package-centric semantics. For example
> the directory/file watch could run once all the involved packages have been
> processed, which doesn't *have* to be after everything else has completed,
> ie post transaction.
>
> To answer the question... that %posttrans doesn't run on erasures is a
> kind of two-fold thing:
> a) it's not intended to, there's supposed to be %postuntrans for that
> b) not implemented due to rpm internal issues/limitations
>
> %postuntrans might get implemented some day, but it's not the answer to
> this problem.
>
> P.S. Did you send this question privately on purpose? Just for the record,
> I wont mind if you reply back to / cc rpm-maint list.
>
>        - Panu -
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rpm.org/pipermail/rpm-maint/attachments/20080420/bfcc39e0/attachment-0001.htm 


More information about the Rpm-maint mailing list