Your knowledge about Slackware is so epic high, that you yet have to figure out that that thing is the installed packages records, an essential piece for proper work of the packages management in the Slackware.

What a silly statement af.

Logging is useful where it is merited. Unless you have a system doing unexpected things there is little use for logs, generally. Certainly there is little point in collecting days/weeks/months worth of logs in such scenarios. However should a use case arise for logging a flaw then the facility could be turned on as required. There is no requirement to unnecessarily compile system logs of redundant info repeating itself over and over again. For this reason my own policy has been to discard logs at every boot. The info is largely irrelevant. Second, you're not going to id a hacker from your standard iptables logs.

rsyslog collects very generic system generated logs and tonnes of it. Many of you call yourselves sa's and come across as clutching to this info like there's no tomorrow. In a well tuned system much of this info is largely superfluous.

Now the point of this topic wasn't to have a discussion or debate. I asked if package logs can be audited elsewhere. The answer should have been a succinct No. It's is a terrible idea to have /var/logs/packages when there is practically all of /var/* to choose from.

So you are odds with discarding logs and yet you're making this suggestion to place the package logs elsewhere. That's contradictory, so why bother? Best keep your trap shut.

/var/lib contains libraries, binaries. This is not an appropriate place for text file audits of packages either. Fool.

I can remember having a discussion with Pat about this here on LQ a good while back. He said that the original idea was to have them in /var/adm/packages, but that the FHS came along and decreed that /var/adm should be a symlink to /var/log which kind of made the location nonsensical. If I remember rightly, he said that he regretted following the standard and wished he'd just stuck with /var/adm.

/var/lib/packages is probably the right place for them based on the current standards, but the change would be disruptive as people are now used to them being under /var/log/.

Personally, I never really liked '/var/lib' as a name. I always thought /var/state was a better name to hold this sort of stuff but again, the FHS decided otherwise.

2 members found this post helpful.

@linuxbawks

Seems like that makes no sense for someone to try to explain you that those files are NOT "text file audits of packages", because you are so proud for nothing that you probably are unable to assimilate that information.

Good luck with your endeavor.

I know that Patrick's statement. And he's right, it is a bit strange to have the packages database in a directory dedicated for log files.

Sucks to be you. Literally.

Don't forget, there's also /var/log/scripts/ too, as well as the corresponding /var/log/removed_{packages,scripts} directories.

Yeah, I don't think it is worthwhile to alter these locations to enable /var/log in tmpfs, unless you're on LVM to create separate LVs for them, as Richard Cranium said.

What's your system workload like to even consider putting /var/log in tmpfs in the first place?

Have you looked at the FHS? /var/lib/ has nothing to do with libraries. It is different from /lib/ and /usr/lib/. Maybe you should verify what you're posting before you call someone a fool...

If we follow the FHS, /var/lib/ is probably the best place for the package data to move to.

Actually /var/cache/ has a requirement that all data should be able to be deleted and, if needed, regenerated.

One could always tweak logrotate files in /etc/logrotate.d to minimize log files size

Yes this is a way around it. Or symlink the relevant files elsewhere.
However I still think it's bad design to fix /var/log/packages. This could easily be made into a setting and pushed into the env or a conf file. For those string and obtuse jammed and fixated with /var/log/packages can still have it their way by leaving said setting alone. There's no reason to literally hijack /var/log in what's really such a fledgling packaging system.

You miss the point. Logging to disk also creates an inordinate number of writes for very little return.

Do you maintain any servers in production?

You seem to be talking purely from a desktop user's viewpoint.

In production, it can take months for the results of an issue to surface. In those circumstances, it is helpful to have several months worth of logged information.

Since you're not interested in keeping logs, why not turn off logging altogether? It is easy enough to do.

Which is why I asked the question: what's your workload such that you'd care for disk writes in the first place?

Is this on an embedded environment, or one where there's such high level of write amplification and/or wear that you'd care to limit disk writes as much as possible? And to follow-up: would the effort to reduce disk writes be lesser than to say, get/replace disks for cheap?