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