Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#40211 - [terminus-font] 75-yes-terminus.conf exists in filesystem

Attached to Project: Community Packages
Opened by Martin Schnitkemper (Martin-MS) - Sunday, 04 May 2014, 09:17 GMT
Last edited by Alexander F. Rødseth (xyproto) - Saturday, 24 October 2015, 17:05 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Alexander F. Rødseth (xyproto)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


Description: Update failed with error "/etc/fonts/conf.d/75-yes-terminus.conf exists in filesystem"

Additional info: Seems like /etc/fonts/conf.d/75-yes-terminus.conf is a symbolic link to /etc/fonts/conf.avail/75-yes-terminus.conf and the package installer tried to install the link instead of create it. As a workaround I removed the package before I installed it again.

Steps to reproduce: Upgrade from package version 4.38-4 to 4.38-5
This task depends upon

Closed by  Alexander F. Rødseth (xyproto)
Saturday, 24 October 2015, 17:05 GMT
Reason for closing:  Fixed
Comment by Alexander F. Rødseth (xyproto) - Sunday, 04 May 2014, 11:59 GMT
Thanks for reporting. Would you mind testing if 4.38-6 also has this problem?
Comment by Martin Schnitkemper (Martin-MS) - Sunday, 04 May 2014, 14:31 GMT
Thanks for your response. I tried to update from 4.38-4 to 4.38-6 and got still the same issue that /etc/fonts/conf.d/75-yes-terminus.conf exists in filesystem and update process aborts.
Comment by Daniel Micay (thestinger) - Sunday, 04 May 2014, 14:56 GMT
This was an unpackaged file and is now part of the package. I don't think there's a way to avoid user intervention since even pre_upgrade runs after the check for conflicts.
Comment by Doug Newgard (Scimmia) - Sunday, 04 May 2014, 15:26 GMT Comment by Alexander F. Rødseth (xyproto) - Tuesday, 06 May 2014, 14:19 GMT
Thanks, Doug and Daniel.

Changed this issue to a feature request.

Added /etc/fonts/conf.d/75-yes-terminus.conf to the backup array in the PKBUILD.
Tested and confirmed that it works without user intervention. The updated package will appear in [community] shortly.

Martin, does it work as expected now?
Comment by Martin Schnitkemper (Martin-MS) - Tuesday, 06 May 2014, 21:01 GMT
First I installed version 4.38-4 and updated then to the current version 4.38-7 and no user intervention was required. Same result if I install version 4.38-7 without a prior version.
However, due to the backup-statement in PKBUILD a pacsave symlink remains now in the folder after removing the package, unless you use pacmans -n-option.
I think we can live with this solution since the system update is no longer interrupted by this package.
Comment by Alexander F. Rødseth (xyproto) - Wednesday, 07 May 2014, 09:43 GMT
That a backup file is left behind when _overwriting_ a file in /etc that was not previously part of the package is _not_ a problem. That's how it's supposed to work.
I could have just closed this bug and said "use --force if you wish to overwrite, read the wiki", but took some extra steps to solve this.
I insist that this is not barely a solution you "can live with", but a pretty smooth solution to what was really just a minor discomfort.
Comment by Daniel Micay (thestinger) - Wednesday, 07 May 2014, 14:01 GMT
I agree, the backup solution is more convenient than what we usually do.
Comment by Yuri Kanivetsky (x-yuri) - Saturday, 26 September 2015, 01:16 GMT
  • Field changed: Percent Complete (100% → 0%)
It happens again. Every time I install new version. I delete terminus-font, install v4.39-1, then v4.40-1 and get a warning, then v4.40-2 and get a warning.
Comment by Doug Newgard (Scimmia) - Saturday, 26 September 2015, 01:17 GMT
I should explain x-yuri's reopen comment. He was pointing to the issues in this thread: Speculation there was that the error was a one time thing, so I told him to request reopen again if it happened again. It apparently has. It would seem that pacman doesn't deal with symlinks in the backup array very well.
Comment by Yuri Kanivetsky (x-yuri) - Saturday, 26 September 2015, 09:54 GMT
I can imagine these 3 cases of what might change here: 1) user changed symlink's destination (the file symlink points to), 2) user changed symlink (where symlink points to), 3) user replaced symlink with a regular file. With 2nd and 3rd cases having obvious solution, what would you expect pacman to do in the first case?
Comment by Yuri Kanivetsky (x-yuri) - Saturday, 26 September 2015, 17:07 GMT

> the backup solution is more convenient than what we usually do

Daniel, what you usually do exactly?
Comment by Yuri Kanivetsky (x-yuri) - Sunday, 27 September 2015, 07:33 GMT
Sorry, my bad, I failed to notice that second warning (from installing 4.40-2) was about creating .pacsave, not .pacnew. As it appears, the symlink was removed from backup array in 4.40-2:
Comment by Alexander F. Rødseth (xyproto) - Sunday, 04 October 2015, 18:00 GMT
Is the current PKGBUILD working for everyone involved? Can I close this issue?
Comment by Yuri Kanivetsky (x-yuri) - Monday, 05 October 2015, 10:48 GMT
From what I can tell, yes. It shouldn't give a warning anymore, should it?