You are not logged in.
Pages: 1
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)
Offline
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.
Offline
Could just as easily be handled by a simple wrapper script.
Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest
Offline
Or with hooks once those changes get pull for pacman-5.0.
Offline
Pages: 1