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

[Allan McRae]

On 12/04/14 01:21, Olivier Brunel wrote:
> 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.

I agree fully here.

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


I am going to propose moving the configuration parsing code (ini.h,c) to
the backend.  (I am assuming this is used for hook config parsing
without looking at the patches.)  All front-ends to libalpm to need to
be able to handle the hooks so common code for this is needed.

So...:
 - ini.h,c moved to backend - functions exposed to library
 - pacman.conf reading adjusted
 - hook parsing and triggering -> backend

Allan