WARNING: Unique directory /usr/share/ghostscript/9.54.0/Resource/Init/ contains new files
 

During the zen moments of watching slackpkg upgrade-all output scroll by, I noticed a few warning messages, which boil down to the one in the title. So I looked.

Eh, some file created, probably in the course of ghostscript installation. Google says ghostscript generates a font mapping of some sort and stores it in cidfmap. A nothing burger, but a bit of cruft left behind.

The date is odd, though. My system was freshly built on August 10, which, if my calculations are correct, comes after March 31. So the file is older than the package installation, but not part of the package manifest. Curious.

The new version of ghostscript has the same file, created today, but prior to my update ritual.

The package manifest for the new version of ghostscript does not contain this file, but it circles around it:

My hypothesis, therefore, is that future warnings await me and will likely reveal themselves sometime after version 9.56.0 of ghostscipt is released. For the moment...

I know; I'm a wild man.

Interesting.. I've had my install for quite some time.

So lets see whats in every old version's folder

Seems cidfmap is left behind every time. I think ill be doing some rm -rf's myself.

cidfmap gets treated like any other config file. It has a ".new" extension in the Slackware package. This ensures that upgrading the package doesn't overwrite any custom config you might have.

So when you remove the package, it gets left behind. This is expected.

Wild as in Daniel Boone? Or Jed Clampett? Either way, that's the right way to "fix" it... provided that you don't have any customisations in there that you want to keep.

Sure, but when you upgrade a package, most packages upgrade to the same destination. So .new files work as expected, i.e. you are asked to consider a newer *.new file if you've made changes to your old config files etc. Because ghostscript creates a new folder each time (that includes the version number), it doesn't seem to act like other packages.

Doesn't really bother me to be honest, I was happy to manually remove unneeded old files. But its an interesting catch by the original poster. I wonder if there is a better way to handle the cidfmap.new file with the ghostscript doinst.sh script?

I probably found the culprit in ghostscript.SlackBuild

line 185
:doh:

Hilarious :D

There might be... but this could be one of those situations where the solution is worse than the issue itself. You say that you've had your installation for "quite some time," and after all of that time, it was carrying 64Kb of excess config files. Is that a big problem?

I absolutely agree with everything you said.

But if there is an elegant solution that isn't worse than the issue itself, it would be nice. I certain wont lose sleep over it either way!

On the principle of no surprise, I think it is best to leave things as is. Consider a user that has modified the config then decides to reinstall the existing package. The user would expect the existing config to be preserved. Clearing out this stale config is something I have done before.

Yeah you are almost certainly correct. I dont mind occasionally deleting stale files. Not suggesting anything, just thinking aloud. What if the cidfmap file is stored in a fixed location, say under /etc/ghostscript or /usr/share/ghostscript/ghostscript-settings or something. Then the ghostscript package can have a symbolic link to the file. Would allow one to automatically carry over modifications when upgrading (or reinstalling), and allow the symbolic link to be deleted when upgrading not leaving stale directories?

I'm sure that's probably well into the "could be one of those situations where the solution is worse than the issue itself" territory rkelsen mentioned.

Anyway, allend, as a fellow Melbournian, might be time to baton down the hatches, I hear we are in for a bunch of wild weather tonight.

@avian - :hattip:
Wild weather? Nah, just some spring wind and rain. I could slip on one of my Slackware T-shirts. There was a long period when I thought I was the only one in Melbourne with those.

I see no problem at all. It works s expected. Besides couple of rules there is no rules at all in Slackware. Now I can recall only two rules. Init system and using generic kernel. Beside that nothing comes to my mind. Shortly: there is no expected way for work. Rather we expect Slackware to be stable even supporting our own phantasies. Let OP has hope that accidents that something caught it's eyes in log won't happen often. In other case, well, managing system may became very boring.

I'd highly doubt that. Back in the day, there was a whole section of Linux Users of Victoria dedicated to Slackware. I met a few of them back in the late 90s/early 2000s. One of them put a particular version of Slackware onto a CD for me, but I can't remember which. Maybe 7.1 or 8.0. Anyhow, he had access to high speed broadband at his office, and his employer let him download it. I was still on dial up at home, and my employer had stricter rules about using the internet.

I'm in the NW part of the metro area and that rain hasn't started here yet. By the look of the radar it might not happen for a few more hours.

This was discussed before here:
https://www.linuxquestions.org/quest...er-4175666296/

None of the replies in either thread have changed my opinion that the dot new handler should not be used for config files with the version number it their path. It causes inconsistent behavior, leaves cruft in the filesystem and doesn't solve any problem.

The amount of "cruft" is 8kb each time you upgrade this program. A small amount compared to the hours someone might have spent customising this file...

Ideally, the upstream authors should stop changing the file's location.