[pacman-dev] [PATCH 0/2][WIP][RFC] hooks

[Olivier Brunel]

On 04/11/14 16:48, Andrew Gregory wrote:
> On 04/11/14 at 11:49am, Olivier Brunel wrote:
>> On 04/11/14 01:59, Andrew Gregory wrote:
>>> This is a lazy conversion of a work-in-progress hook implementation from my
>>> pacutils library [1] (hence all the pu_* prefixes).  I have left out several
>>> previously outlined features that I do not see as essential to an initial
>>> implementation and can be easily added later if they are actually needed:
>>>  * mid-transaction hooks (PreInstall, PostRemove, etc..)
>>>  * passing triggering packages/files to the hook
>>>  * system vs user hook directories with overriding (use backup=() instead)
>>>  * specifying hook order
>>>
>>> Some included features not previously discussed that I know of:
>>>  * pre-transaction hooks can cancel the transaction
>>>  * multiple triggers per-hook
>>>
>>> Major TODO's:
>>>  * documentation
>>>  * error handling
>>>  * use _alpm_run_chroot or similar to run the hook instead of system()
>>>
>>> I have chosen to implement hooks entirely in the front-end as the only
>>> alternatives I came up with were having alpm do the file parsing itself or
>>> having pacman repeatedly reset the list of hooks as packages are added/removed.
>>
>> Although I welcome the addition of hooks, I don't think it's a good idea
>> to make it a frontend/pacman-only implementation.
>>
>> Just like today one wouldn't consider a package operation (e.g. install)
>> to be complete without dependencies handling or the scriptlets run,
>> tomorrow it won't be considered complete without hooks having been
>> processed. So it should definitely be an ALPM thing.
>>
>> In fact, one of the reason for hooks has been said to replace "common"
>> install files with hooks, so it is thought of as part of the whole
>> operation process, and therefore would mean any frontend not
>> reimplementing hooks exactly like pacman does would be broken! This
>> doesn't sound good/right to me.
>>
>> Frontends could do the parsing themselves, but then only set things up
>> in ALPM, much like they set repos or which packages/groups to ignore.
>> But then, it's ALPM who makes use of it, and maybe ignores a package or
>> asks user about it, not the frontend.
>>
>> Additionally, since there was talk that if a package installs hook
>> files, they should be taken into account within the transaction (for
>> remaining package operations), it seems it might be better to have ALPM
>> actually do the parsing, since it could then also load any new hook
>> files added as part of a package operation.
>> Frontends would then only set which folders are to be used/looked in for
>> hook files. (And there'd be an event INVALID_HOOK or something, for when
>> ALPM fails to parse a hook file, and will therefore ignore it.)
>>
>> What is the problem with ALPM doing the parsing, that you didn't want to
>> do it?
>>
>> Cheers,
>> -j
> 
> Right now there is a clear separation between what alpm and pacman are
> responsible for reading.  pacman handles all of the configuration and
> alpm handles the actual package (which includes any install scripts).
> Despite their similarity to install scripts, every discussion of hooks
> so far has anticipated them being user-configurable, making them
> configuration files more in front-end territory.  Having alpm be
> responsible for reading them would alter the relationship between alpm
> and the front-end.  I don't think that's the correct solution and
> won't be implementing it without a clear consensus first.
> 
> The fact that this would introduce additional work for front-ends is
> unfortunate, but doesn't necessarily mean that the back-end is the
> correct place for this.  Any alpm front-end already likely parses
> pacman.conf which is much more difficult than parsing the hook files.
> Even our own scripts in contrib/ don't parse it the same way pacman
> does.
> 
> Having the front-end parse and configure the hooks for alpm upfront
> doesn't really work because we would need to update the hooks in alpm
> as the hook files were added/removed/updated which would involve the
> same amount of work as the current implementation.
> 
> I do hope to move *some* of this into alpm, particularly the actual
> execution of the individual hooks and possibly the selection of which
> hooks to run at a given time.  The parsing and triggering I currently
> intend to keep in the front-end.

Well, I don't think the triggering should be up to the front-end really.
They could do the parsing and setting up hooks in ALPM, much like they
do repos, but deciding if/when to trigger hooks, and actually triggering
them, should be up to ALPM in my mind.
Just like a frontend might tell ALPM not to run scriptlets, but it won't
decide when to run them, nor ran them itself.

IOW, if the frontend is the one deciding when to trigger hooks and
actually triggering them, then hooks are nothing else than a user
feature, but cannot be thought of as part of the package operation,
since it's not part of ALPM.

Yes, hook files are user-configurable and therefore more like
configuration files, and I can see why that makes them more frontend
territory, but they are also intended to replace (some) install files,
and they will also be provided by/within packages (in Arch, though I
would assume other places it's used as well), so they clearly aren't
just user configuration.

By which I mean, regardless of what frontend a user uses, which may also
parse pacman.conf or could use another configuration file completely,
every package operation done will remain consistent, in that it will be
processed just as with pacman (assuming ALPM is setup the same, ofc).
That's the point of having a library w/ frontends.

But if hook files are provided by packages themselves, clearly the
syntax of those files isn't pacman-defined, but ALPM-defined, and that
even if pacman were to do the parsing.

Or, that would mean hooks are a user feature of pacman (the frontend),
and Arch decides to "abuse" that feature, making pacman the only
frontend that *can* be used, because it (Arch) doesn't just rely only on
ALPM to do its package management anymore (of which pacman was merely
the official frontend) but (via its package-provided hook files) would
actually rely on a pacman-specific feature, for package operations to be
performed completely/correctly. That doesn't sound right to me.

-j

> 
> apg
>