prelink should not mess with running executables

[Sam Varshavchik]

Garrett Holmstrom writes:

> On 2012-07-19 15:57, Sam Varshavchik wrote:
>> The fact that the same consequences can occur from
>> upgrades, or some other unspecified events, is irrelevant, because
>> appropriate measures /can/ be easily put in place, to take the
>> appropriate action when upgrading, and most likely for whatever those
>> other mysterious reasons might be. But this is not easily doable with
>> prelink, without resorting to unwarranted nonsense, like inotify or
>> similar workarounds.
>
> Why is it simultaneously acceptable to put measures in place to deal with  
> package replacement and unacceptable to put measures in place to deal with  
> prelink when each of these methods of file modification has a well- 
> documented and well-supported method of allowing you to react to them?

Because package hooks are an established mechanisms that all packages can  
use, and share the benefits of.

On the flip side, this proposition is for every app who needs to do it, they  
will need to reinvent the same wheel. Furthermore, several different package  
hooks provide orderly means for implementing package-specific actions at  
various stages of the upgrade process, in an orderly fashion, including  
before any actual file replacement takes place.

Meanwhile, with inotify, by the time you get poked in the eye, it's already  
too late.

Is it possible for this basic, elementary, fact to be understood, by someone?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120720/03839f5a/attachment.sig>