You are not logged in.
Hi,
It might be not an issue. Just wanted to confirm. The full warning is like so:
warning: /etc/fonts/conf.d/75-yes-terminus.conf installed as /etc/fonts/conf.d/75-yes-terminus.conf.pacnew
What I find strange is:
$ ls -al /etc/fonts/conf.d | grep terminus
lrwxrwxrwx 1 root root 34 May 8 2014 75-yes-terminus.conf -> ../conf.avail/75-yes-terminus.conf
lrwxrwxrwx 1 root root 34 Aug 22 00:22 75-yes-terminus.conf.pacnew -> ../conf.avail/75-yes-terminus.conf
Neither the link, nor the target has changed. Why did `pacman` even complain?
Offline
Offline
Um, meaning what exactly?
when pacman upgrades a package which includes a new config file created by the maintainer differing from the currently installed file, it writes a .pacnew config file.
A .pacnew file may be created during a package upgrade (pacman -Syu, pacman -Su or pacman -U) to avoid overwriting a file which already exists and was previously modified by the user. When this happens a message like the following will appear in the output of pacman:
warning: /etc/pam.d/usermod installed as /etc/pam.d/usermod.pacnew
But as I said, the file hasn't changed:
$ f=etc/fonts/conf.avail/75-yes-terminus.conf
$ diff -u <(tar xOf terminus-font-4.39-1-any.pkg.tar.xz "$f") <(tar xOf terminus-font-4.40-1-any.pkg.tar.xz "$f"); echo $?
tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
tar: Ignoring unknown extended header keyword 'SCHILY.fflags'
0
Offline
Looks like the file was added to the backup array for reasons that I can't follow: https://bugs.archlinux.org/task/40211
Unfortunately, pacman seems to think that the original file has a hash:
# pacman -S --debug terminus-font #upgrading from a fresh install of 4.39-1
[...]
debug: checking hashes for etc/fonts/conf.d/75-yes-terminus.conf
debug: current: (null)
debug: new: (null)
debug: original: 6a99d70d1567c92eb37e47035f17b3d9
debug: action: keeping current file and installing new one with .pacnew ending
[...]
This seems like a bug in pacman, but backing up a symlink in the first place seems like a strange thing to do.
EDIT: Possibly not a bug in pacman after all. It only thinks that 4.39-1's symlink has a hash, it correctly reports 4.40-1's symlink's hash as "(null)". I think this may just have been just a packaging hiccup.
Last edited by WorMzy (2015-09-03 10:08:32)
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
but backing up a symlink in the first place seems like a strange thing to do
I believe the intention was to back up whatever is there, symlink or not. Symlink might get replaced with a regular file by user. Does it makes sense now?
Additionally, do you know what are current, new and original versions of a file to pacman? If I had to answer, I'd say, that current is the one in the filesystem, new is the one in the package being installed, and original is the one in the currently installed package. Then original version shouldn't have a hash as well.
Last edited by x-yuri (2015-09-26 09:55:33)
Offline
WorMzy wrote:but backing up a symlink in the first place seems like a strange thing to do
I believe the intention was to back up whatever is there, symlink or not. Symlink might get replaced with a regular file by user. Does it makes sense now?
Kinda? I don't know the likelihood of a user replacing that file vs. editing the actual file in conf.avail, or overriding the settings in a higher numbered config file. My personal opinion is that everything in conf.d should be a symlink to something in conf.avail.
Additionally, do you know what are current, new and original versions of a file to pacman?
Your understanding is correct, see https://wiki.archlinux.org/index.php/Pa … _explained
Since symbolic links don't have any content, they shouldn't have a md5sum.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
What would you do then, concerning terminus-font package? Added /etc/fonts/conf.avail/75-yes-terminus.conf to backup array instead? Didn't add neither of them?
UPD I'm now looking into the source Here are some interesting links.
Last edited by x-yuri (2015-09-26 18:11:23)
Offline
What I'd do isn't relevant. However, none of the other font packages (e.g. fontconfig, ttf-dejavu, ttf-liberation) do this. They either install the symlinks afterwards, or package the symlinks without backups, or don't install the symlinks at all. There doesn't seem to be a consensus among packagers on how to handle conf.d files..
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
Unfortunately, pacman seems to think that the original file has a hash:
...
EDIT: Possibly not a bug in pacman after all. It only thinks that 4.39-1's symlink has a hash, it correctly reports 4.40-1's symlink's hash as "(null)". I think this may just have been just a packaging hiccup.
AFAICT, pacman treets files and symlinks equally. Meaning, symlink's hash is a hash of symlink target file. It's just that the target file might not exist yet:
debug: checking hashes for etc/fonts/conf.d/75-yes-terminus.conf
debug: current: (null)
debug: new: (null)
debug: original: 6a99d70d1567c92eb37e47035f17b3d9
debug: action: keeping current file and installing new one with .pacnew ending
warning: /etc/fonts/conf.d/75-yes-terminus.conf installed as /etc/fonts/conf.d/75-yes-terminus.conf.pacnew
debug: extracting /etc/fonts/conf.avail/75-yes-terminus.conf
But that brings up the question of where original hash comes from? Are they stored somewhere?
Offline