changing pacman

archlinux20130905 · 2014-11-01 17:40:59

Dear all,

If one looks at the documentation for pacman.conf:

https://www.archlinux.org/pacman/pacman.conf.5.html

One can see that there is no command that would allow a user to execute his or her own programs under certain circumstances, when pacman is executed (except XferCommand). What I think about, is something like this:

PacNewFilesCommands = /path/to/a/list.of.pacnew.files.and.their.corresponding.commands

Each time before creating a pacnew-file Pacman would look in the textfile specified under PacNewFilesCommands and determine, whether the filename (e.g. ntp.conf) is within the textfile. The textfile may look like this:

ntp.conf = /path/to/special/program/that/handles.ntp.conf
locale.gen = /another/path/locale.gen.handler

and so on. For example if the pacnew-File has to be created for ntp.conf then instead pacman might call handles.ntp.conf and pass the contents of ntp.conf.pacnew to handles.ntp.conf. Programs and scripts like handles.ntp.conf would have to be written by the Archlinux user since each user might have different requirements for how to handle a specific situation. This would make it possible to run pacman as a service that could for example update the system during startup. However for the pacman-commandline-utility this function could be disabled by default and only enabled if one passes an option like --enable-individual-pacnew-processing .

So pacman -Syyu --enable-individual-pacnew-processing may call handles.ntp.conf and locale.gen.handler during the system upgrade process instead of creating ntp.conf.pacnew and locale.gen.pacnew. What would happen inside these programs would be up to the user. For example handles.ntp.conf.py might do something like this:

#!/usr/bin/env python

import sys

f1 = open(sys.argv[1])
f2 = open('/etc/ntp.conf', 'w')

foundServerOptionsLair = False

for k in f1:
 if k.startswith('server ') and not foundServerOptionsLair:
  f2.write('server my.beloved.ntp.server\n')
  foundServerOptionsLair = True
 else:
  f2.write(k)

f2.close()
f1.close()

Or it could be something entirely different. I realize that programs like this could never adapt to different unexpected future situations. (For example someone may decide that instead of the server-command the SourceOfTime-command should be used inside ntp.conf and thus the program above would overwrite the original configuration file with the new configuration and thus destroy the my.beloved.ntp.server-setting in the original ntp.conf. However certain people like me are willing to take that risk for a more comfortable "semi-automatic" pacman-command that could update the system during startup and the user deals with the negative consequences if they arise.)

What do you think about this?

Last edited by archlinux20130905 (2014-11-01 17:45:10)

karol · 2014-11-01 18:30:36

Manually dealing with pacnew files is already supported and foolproof if the user knows what he's doing.
People use different configs so many people would have to use custom config files for their pacnew situations.

You can script certain things, e.g. always removing mirrorlist.pacnew, since you're using your own mirrorlist and you keep it updated with a script you run via crond / systemd timer.

Mr.Elendig · 2014-11-02 10:49:19

Could just as easily be handled by a simple wrapper script.

Allan · 2014-11-02 11:19:52

Or with hooks once those changes get pull for pacman-5.0.

Arch Linux

#1 2014-11-01 17:40:59

changing pacman

#2 2014-11-01 18:30:36

Re: changing pacman

#3 2014-11-02 10:49:19

Re: changing pacman

#4 2014-11-02 11:19:52

Re: changing pacman

Board footer