I'm not super invested in this, but I'll throw out something I've been considering for some time: a pair of config settings, one to make --sync
imply --sysupgrade
and one to imply --refresh
. The latter could potentially be tied into the db expiration that has been floated around as well. Work started here: https://github.com/andrewgregory/pacman/compare/master...auto
I think the proper fix is to adjust the config parsing api so that we don't have the weird situation we have now with the path as both an argument and config struct member. As a quick fix, I think this is probably fine. It will prevent the sysroot from being reflected in the Conf File for --verbose though.
Example isn't great, but it illustrates the intent. I think expecting front-ends to be responsible about committing with FLAG_NOLOCK
is reasonable, but if we're worried about accidents, we could add a separate flag.
This is useful to allow front-ends to manage the lock file themselves, allowing them to ensure database consistency across multiple commands, e.g.:
paclock --lock
pacinstall --no-lock foo
# foo is guaranteed to be installed until the db is unlocked
paclock --unlock
Andrew Gregory (448b43a5) at 12 Mar 15:24
allow committing transaction without a lock file
Andrew Gregory (f6ac4a05) at 12 Mar 15:22
allow committing transaction without a lock file
As the second most senior pacman dev and developer of pacutils, I can tell you pacutils is the preferred solution for scripting. None of us have the time at this point to try to add and maintain a scripting-centric interface for pacman, especially when pacutils is explicitly made for scripting and already meets most scripting needs.
Andrew Gregory (9f6c0817) at 04 Mar 01:37
Setting sysroot to / is not the same as having no sysroot, because the sysroot is prepended to ALL config paths including relative ones:
$ cd /etc $ pacman --config=pacman.conf error: config file /pacman.conf could not be read: No such file or directory
Andrew Gregory (7016adcb) at 18 Feb 23:22
alpm_release
has changed and this no longer applies or makes sense as-is. It seems to me that the critical state is STATE_COMMITING
. Outside of that we don't actually need the lock file to stick around on an aborted transaction because nothing has actually been done (except potentially hooks). So, I think alpm_release
and trans_release
could bail out if STATE_COMMITING
and otherwise free all resources, including the lock file.
Another possibility is opening critical directories early and using the fd with the various *at functions. That would be robust against mid-transaction fs changes and hopefully reduce the number of path strings we need to construct:
/* in alpm_initialize */
handle->cache_fd = open(handle->cachedir, O_RDONLY|O_DIRECTORY);
/* some time later... */
int pkg_fd = openat(handle->cache_fd, pkg->filename, O_RDONLY);
load_pkg(pkg_fd);
Andrew Gregory (0a394144) at 07 Feb 12:32
Clearly our db parsing error path was not being tested very well. Fixes pushed.
Andrew Gregory (f20ff5be) at 07 Feb 08:38
validate package metadata after loading
... and 3 more commits
Add the same name and version checks makepkg does to alpm. Most of these are essential for alpm to function correctly. The package name character check is also to avoid confusion with shell syntax or option parsing (e.g. a package named --foo).
Andrew Gregory (3d71a8c4) at 06 Feb 18:02
validate package metadata after loading
Andrew Gregory (4202b964) at 06 Feb 17:56
validate package metadata after loading
... and 1 more commit
Why don't you simply name the packages in your repo foo
and bar
?