Difference between revisions of "User:Allan/Pacman Hooks - Version 1"

From ArchWiki
Jump to: navigation, search
(Proposed Directory Layout)
 
(27 intermediate revisions by 11 users not shown)
Line 5: Line 5:
  
 
'''Long Version:'''
 
'''Long Version:'''
Many packages have install files that perform a common task; e.g. adding/removing info files the info directory file, installing/uninstalling gconf schemas, updating the font/desktop/icon cache. It would be good if pacman was extendible through a hooks mechanism so that these could be handled automatically.
+
Many packages have install files that perform a common task; e.g. adding/removing info files in the info directory file, installing/uninstalling gconf schemas, updating the font/desktop/icon cache. It would be good if pacman was extendible through a hooks mechanism so that these could be handled automatically.
  
 
=Hooks=
 
=Hooks=
Line 11: Line 11:
 
A hook would need
 
A hook would need
 
* Information on when the hooks should be run (see "Types of Hooks" below)
 
* Information on when the hooks should be run (see "Types of Hooks" below)
* A list of files or globs that trigger the running of the hook
+
* A list of files or globs that trigger the running of the hook, alternative a package name that trigger the hook
 
* The actual hook script
 
* The actual hook script
  
Line 21: Line 21:
  
 
* Hooks that run for every matching file (e.g. updating the info directory). Separate versions would be needed for install and removal of the files.
 
* Hooks that run for every matching file (e.g. updating the info directory). Separate versions would be needed for install and removal of the files.
 +
 +
* Hooks that run for every matching package. As with files there would be separate versions would be needed for install and removal of the files.
 +
 +
 +
--[[User:Diego|Diego]] 11:20, 6 July 2010 (EDT)
 +
: Unless "Hooks that run for every matching package" run if the package is ignored, I would like to suggest:
 +
:: Hooks that run when an ignored package would have been installed if it wasn't ignored.
 +
 +
-- [[User:Gour|Gour]] 02:50, 26 July 2010 (EDT)
 +
: I'd like to see Hooks implemented so that we can get support for Pacman in [http://joey.kitenet.net/code/etckeeper/ etckeeper].
 +
 +
--[[User:Vi0L0|Vi0L0]] 9 August 2010
 +
: I also like idea of hooks, i would use it to auto-recompile fglrx module (this could be used for any module) with every kernel update. Right now i'm using mkinitcpio's hook, but it's impossible to build fglrx module with main kernel26 update (ie. 2.6.34-ARCH->2.6.35-ARCH) simply because kernel26-headers package is updated after kernel26 package, and so there's no headers to build module.
 +
 +
--[[User:Boyska|Boyska]] 05:15, 10 January 2011 (EST)
 +
: It would be useful for script like firebrand or similar, that needs to be launched after every firefox upgrade
 +
 +
--[[User:Rene|Rene]] 00:25, 25 March 2013 (CET)
 +
: I stumbled upon this while trying to ascertain if there was a way to have my mirrorlist.sh shell script (which uncomments the "## Netherlands" section of the mirrorlist file) run automatically by pacman when upgrading pacman-mirrorlist. This to say that this would also be quite welcome from an automatic maintenance point of view, not just as a way to minimise duplication for standard operations such as .info file installation.
  
 
=Proposed Directory Layout=
 
=Proposed Directory Layout=
Line 27: Line 46:
 
                       ''info-remove''
 
                       ''info-remove''
 
                       ''ttf''
 
                       ''ttf''
 +
                      ''etc-install''
 +
                      ''Postkernelupdate''
  
 
(Dan: why bother with 'hooks.d/' and not just 'hooks/'?)
 
(Dan: why bother with 'hooks.d/' and not just 'hooks/'?)
  
 
(Allan: can't really comment given I actually have no idea what the .d is for with folders in /etc)
 
(Allan: can't really comment given I actually have no idea what the .d is for with folders in /etc)
 +
 +
(Jeff: .d is a very loose standard that signifies a configuration '''_d_'''irectory for a given package. This is usually for packages that have multiple config files to avoid cluttering /etc. If there is a config file named the same as the directory (suffix excluded) it is starting to become customary to add the .d. With that in mind, if there is no hooks.conf then hooks.d may as well be just hooks. Either way, it is just a preference, not a standard.)
 +
 +
(I don't like to have package-generated config files in /etc. The more modern model seems to be to have /usr/lib/pacman/hooks/ for system hooks and /etc/pacman.d/hooks/ for user-generated hooks, or for cleanly overriding/masking system-generated ones [[User:Brain0|brain0]] ([[User talk:Brain0|talk]]) 15:04, 7 September 2012 (UTC))
  
 
=Example Config File=
 
=Example Config File=
Line 43: Line 68:
 
  Files = /usr/share/info/*
 
  Files = /usr/share/info/*
 
  Run = PreRemove
 
  Run = PreRemove
 +
 +
[etc-install]
 +
Files = /etc/*
 +
Run = Install
 
   
 
   
 
  [ttf]
 
  [ttf]
 
  Files = /usr/share/fonts/TTF/*
 
  Files = /usr/share/fonts/TTF/*
 
  Run = Transaction
 
  Run = Transaction
 +
 +
#Example of packagetriggered hook:
 +
[Postkernelupdate]
 +
Package = kernel26
 +
Run = PostInstall
 +
 +
Alternative Configfilesyntax (only showing some of the examples above):
 +
 +
[Install]
 +
Files = /usr/share/info/*
 +
Run = info-install
 +
 +
Files = /etc/*
 +
run = etc-install
 +
 +
[PreRemove]
 +
Files = /usr/share/info/*
 +
Run = info-remove
 +
 +
[PostInstall]
 +
Package = kernel26
 +
Run = Postkernelupdate
 +
 +
Allan: We should allow for the possibility of multiple files lines.
 +
 +
Mårten: In the alternative syntax the section header signals when in time to peform the action and the "Run" parameter is the script to run (better keyword?).
 +
I think it gives a more natural header for the different sections and the section headers have more static content which may help the parsing of the configfile.
  
 +
=Hook Options=
 
Options that will be needed to cover the general range of tasks to be performed by hooks (may need to be more general...):
 
Options that will be needed to cover the general range of tasks to be performed by hooks (may need to be more general...):
* Install - run on installation of a matching file
+
* PreInstall - run prior to installation of a matching file/package
* PreRemove - run prior to removal of a matching file
+
* PostInstall - run after installation of a matching file/package
* PostRemove - run after to removal of a matching file
+
* PreRemove - run prior to removal of a matching file/package
 +
* PostRemove - run after removal of a matching file/package
 
* Transaction - run at end of transaction involving at least one matching file
 
* Transaction - run at end of transaction involving at least one matching file
  
 
We should probably lean on the side of generality here and add options to cover all functions in the install files.  Who knows what uses people could find for this...
 
We should probably lean on the side of generality here and add options to cover all functions in the install files.  Who knows what uses people could find for this...
  
Dan: so to make it clear: The first three hooks run on a per-package basis, and the Transaction hook would only run once for our entire pacman operation, correct?
+
Dan: so to make it clear: The first four hooks run on a per-package basis, and the Transaction hook would only run once for our entire pacman operation, correct?
 +
 
 +
Allan: The first four run on a per matching file basis but otherwise correct. I'm not sure if the by-file hooks should run after each package or at the end of the transaction. (Dan: or what about even the end of each file?)
  
 
=Hook Script Notes=
 
=Hook Script Notes=
  
Hooks that are run once per transation do not need to know what file triggered them (Dan: do we want to rule out the possibility of providing this information?) but hooks that are run once per file will need to be passed the file name.
+
Hooks that are run once per transaction do not need to know what file triggered them (Dan: do we want to rule out the possibility of providing this information?) but hooks that are run once per file will need to be passed the file name.
 +
 
 +
Allan: By the nature of the per-transaction hooks, they should not need file names.  Otherwise they should be per-file hooks.  This would also mean parsing and passing a list.
 +
 
 +
=Notes from Arch .install files=
 +
Common operations:
 +
PostInstall:
 +
  [gconf-install] - install gconf files
 +
  [info-install] - add info pages to info directory file
 +
  [man-install] - add man pages to db
 +
 +
PreRemove:
 +
  [gconf-remove] - remove gconf files
 +
  [info-remove] - remove info pages from info directory file
 +
  [man-remove] - remove man pages from db
 +
 +
Transaction:
 +
  [depmod] - can we do that as a hook?
 +
  [desktop] - update desktop database
 +
  [font] - update the font cache
 +
  [icon] - update gtk icon cache or xdg-icon-resource (how to choose?)
 +
  [mime] - update mime database
 +
  [tex-file] - texconfig-sys rehash
 +
  [tex-font] - updmap-sys
 +
  [vim] - update vim help tags
 +
  [xpdf] - update /etc/xpdfrc
 +
 
 +
 
 +
The following aren't from .install files, but are done in the packaging process and could be moved to this system:
 +
 
 +
* Kernel module compression upon install (would result in a smaller kernel package)
 +
* Manpage and/or info page compression (same as above)
 +
* Manpage and/or info page removal (for those that want a slimmer system)
 +
* Locale removal/pruning (maybe you don't want all 401 MB of it on your system)
 +
 
 +
=Dpkg Trigers=
 +
See the [http://wiki.debian.org/DpkgTriggers Dpkg Triggers] page in Debian's wiki to see what they are doing with "hooks" for their packaging.

Latest revision as of 11:42, 5 July 2013

The Idea

Short Version: Pacman should have hooks to perform common tasks.

Long Version: Many packages have install files that perform a common task; e.g. adding/removing info files in the info directory file, installing/uninstalling gconf schemas, updating the font/desktop/icon cache. It would be good if pacman was extendible through a hooks mechanism so that these could be handled automatically.

Hooks

A hook would need

  • Information on when the hooks should be run (see "Types of Hooks" below)
  • A list of files or globs that trigger the running of the hook, alternative a package name that trigger the hook
  • The actual hook script

Types of Hook

Hooks need to be able to cover a variety of tasks. The following types of hooks are a minimum necessary:

  • Hooks run once per transaction (e.g. updating font cache). These would be run whenever a transaction touches a trigger file (both install and uninstall).
  • Hooks that run for every matching file (e.g. updating the info directory). Separate versions would be needed for install and removal of the files.
  • Hooks that run for every matching package. As with files there would be separate versions would be needed for install and removal of the files.


--Diego 11:20, 6 July 2010 (EDT)

Unless "Hooks that run for every matching package" run if the package is ignored, I would like to suggest:
Hooks that run when an ignored package would have been installed if it wasn't ignored.

-- Gour 02:50, 26 July 2010 (EDT)

I'd like to see Hooks implemented so that we can get support for Pacman in etckeeper.

--Vi0L0 9 August 2010

I also like idea of hooks, i would use it to auto-recompile fglrx module (this could be used for any module) with every kernel update. Right now i'm using mkinitcpio's hook, but it's impossible to build fglrx module with main kernel26 update (ie. 2.6.34-ARCH->2.6.35-ARCH) simply because kernel26-headers package is updated after kernel26 package, and so there's no headers to build module.

--Boyska 05:15, 10 January 2011 (EST)

It would be useful for script like firebrand or similar, that needs to be launched after every firefox upgrade

--Rene 00:25, 25 March 2013 (CET)

I stumbled upon this while trying to ascertain if there was a way to have my mirrorlist.sh shell script (which uncomments the "## Netherlands" section of the mirrorlist file) run automatically by pacman when upgrading pacman-mirrorlist. This to say that this would also be quite welcome from an automatic maintenance point of view, not just as a way to minimise duplication for standard operations such as .info file installation.

Proposed Directory Layout

/etc/pacman.d/hooks.conf
             /hooks.d/info-install
                      info-remove
                      ttf
                      etc-install
                      Postkernelupdate

(Dan: why bother with 'hooks.d/' and not just 'hooks/'?)

(Allan: can't really comment given I actually have no idea what the .d is for with folders in /etc)

(Jeff: .d is a very loose standard that signifies a configuration _d_irectory for a given package. This is usually for packages that have multiple config files to avoid cluttering /etc. If there is a config file named the same as the directory (suffix excluded) it is starting to become customary to add the .d. With that in mind, if there is no hooks.conf then hooks.d may as well be just hooks. Either way, it is just a preference, not a standard.)

(I don't like to have package-generated config files in /etc. The more modern model seems to be to have /usr/lib/pacman/hooks/ for system hooks and /etc/pacman.d/hooks/ for user-generated hooks, or for cleanly overriding/masking system-generated ones brain0 (talk) 15:04, 7 September 2012 (UTC))

Example Config File

This is presented for comments. Many improvements are likely...

[info-install]
Files = /usr/share/info/*
Run = Install

[info-remove]
Files = /usr/share/info/*
Run = PreRemove

[etc-install]
Files = /etc/*
Run = Install

[ttf]
Files = /usr/share/fonts/TTF/*
Run = Transaction

#Example of packagetriggered hook:
[Postkernelupdate]
Package = kernel26
Run = PostInstall

Alternative Configfilesyntax (only showing some of the examples above):

[Install]
Files = /usr/share/info/*
Run = info-install

Files = /etc/*
run = etc-install

[PreRemove]
Files = /usr/share/info/*
Run = info-remove

[PostInstall]
Package = kernel26
Run = Postkernelupdate

Allan: We should allow for the possibility of multiple files lines.

Mårten: In the alternative syntax the section header signals when in time to peform the action and the "Run" parameter is the script to run (better keyword?). I think it gives a more natural header for the different sections and the section headers have more static content which may help the parsing of the configfile.

Hook Options

Options that will be needed to cover the general range of tasks to be performed by hooks (may need to be more general...):

  • PreInstall - run prior to installation of a matching file/package
  • PostInstall - run after installation of a matching file/package
  • PreRemove - run prior to removal of a matching file/package
  • PostRemove - run after removal of a matching file/package
  • Transaction - run at end of transaction involving at least one matching file

We should probably lean on the side of generality here and add options to cover all functions in the install files. Who knows what uses people could find for this...

Dan: so to make it clear: The first four hooks run on a per-package basis, and the Transaction hook would only run once for our entire pacman operation, correct?

Allan: The first four run on a per matching file basis but otherwise correct. I'm not sure if the by-file hooks should run after each package or at the end of the transaction. (Dan: or what about even the end of each file?)

Hook Script Notes

Hooks that are run once per transaction do not need to know what file triggered them (Dan: do we want to rule out the possibility of providing this information?) but hooks that are run once per file will need to be passed the file name.

Allan: By the nature of the per-transaction hooks, they should not need file names. Otherwise they should be per-file hooks. This would also mean parsing and passing a list.

Notes from Arch .install files

Common operations:

PostInstall:
  [gconf-install] - install gconf files
  [info-install] - add info pages to info directory file
  [man-install] - add man pages to db

PreRemove:
  [gconf-remove] - remove gconf files
  [info-remove] - remove info pages from info directory file
  [man-remove] - remove man pages from db	

Transaction:
  [depmod] - can we do that as a hook?
  [desktop] - update desktop database
  [font] - update the font cache
  [icon] - update gtk icon cache or xdg-icon-resource (how to choose?)
  [mime] - update mime database
  [tex-file] - texconfig-sys rehash
  [tex-font] - updmap-sys
  [vim] - update vim help tags
  [xpdf] - update /etc/xpdfrc


The following aren't from .install files, but are done in the packaging process and could be moved to this system:

  • Kernel module compression upon install (would result in a smaller kernel package)
  • Manpage and/or info page compression (same as above)
  • Manpage and/or info page removal (for those that want a slimmer system)
  • Locale removal/pruning (maybe you don't want all 401 MB of it on your system)

Dpkg Trigers

See the Dpkg Triggers page in Debian's wiki to see what they are doing with "hooks" for their packaging.