WARNING: Unique directory /usr/share/ghostscript/9.54.0/Resource/Init/ contains new files
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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.
Code:
eford@dimholt:~$ ls -l /usr/share/ghostscript/9.54.0/Resource/Init/
total 8
-rw-r--r-- 1 root root 6774 Mar 31 15:57 cidfmap
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.
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...
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.
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.
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 wonder if there is a better way to handle the cidfmap.new file with the ghostscript doinst.sh script?
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?
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.
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 -
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 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'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.
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.
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
