> You're contradicting yourself in your first and second paragraph...
Those two paragraphs are talking about different OSs. 1st paragraph is talking about Windows, 2nd paragraph is talking about non-Windows systems with first-class package managers such as ArchLinux, Debian, CentOS, FreeBSD, etc.
> Those proper package managers still rely on the packager doing things correctly
Sure, but the point is you can query what the package manager has done.
> There's plenty of linux packages that creates files during operation in their designated /var/log/xxx /var/db/xxx /etc/xxx /home/xxx/ directories that you're not able to query using the package manager.
That's half true. You can query that /var/db/xxx and /var/log/xxx has been created by the package manager and often the directories (and their contents) will be owned by the user which the daemon runs under.
However I do agree with the point regarding your $HOME directory and actually made that point myself:
> Of course you still have the problem of the software writing files during its operation but that should be limited to $HOME (on POSIX systems) or any path that is writable by the owner / group of the user that application runs as (which should be limited even if it’s a system service).
As an aside, you can also query what files a particular application has open. In fact there are a few ways to do this from querying the /proc/$PID directory through to tools like `lsof`.
I have plenty of files in /var/lib/ that are not owned by any package, same in /var/log/ , /var/cache/ , /etc/sysconfig/ and other directories - their parent directory is owned by a different package than the ones creating these files.
I'm not arguing that a decent package manager is a better than none - but they are solving all issues you claim they do.
Pretty much all OSs, including windows, have ways to view which processes has a file open
> I have plenty of files in /var/lib/ that are not owned by any package, same in /var/log/ , /var/cache/ , /etc/sysconfig/ and other directories - their parent directory is owned by a different package than the ones creating these files.
Got any examples of that? You'd expect only docker to write to /var/lib/docker, mysql to write to /var/lib/mysql. etc. Not discounted that I've overlooked something but a quick look in my /var/lib and it's easy to see what is managed by what. So I'm curious what instances you have of a package manager creating a directory and then a completely unrelated daemon writing to that directory.
> I'm not arguing that a decent package manager is a better than none - but they are solving all issues you claim they do.
I'm not claiming they solve all the problems - in fact I literally identified a few problems they don't solve! Plus even those points I identified aside, there will always be edge cases for thing that package manager should have solved but failed to do so.
Perhaps we should turn this discussion on it's head and discuss better ways to solve the problems people are describing? What would your solution be? Or are you ostensibly agreeing with my points but being contrary just for the sake of playing devils advocate?
> Pretty much all OSs, including windows, have ways to view which processes has a file open
Isn't that literally what I just said? (plus I gave a few examples too).
Thank you. I've not used certbot so excuse the dumb question, but is certbot doing that during install (ie via the package manager) or during program execution (ie when the certbot ELF is launched)?
I shouldn't expect too much in /lib/systemd/system is installed outside of package managers but I agree it does happen and at least they're generally quite easy to identify which service file does what.
crontab is definitely one of those nasty things that can often get forgotten about though (and I speak from unfortunate experience there hah!)
We're really drifting into the domain of Puppet and it's ilk now though.
I'm not sure when those files get created, I just knew about that example off the top of my head because I had to spend some time figuring out why our post-renew hook wasn't working.
dpkg -L helps a lot when figuring out where all the files get spread.
Those two paragraphs are talking about different OSs. 1st paragraph is talking about Windows, 2nd paragraph is talking about non-Windows systems with first-class package managers such as ArchLinux, Debian, CentOS, FreeBSD, etc.
> Those proper package managers still rely on the packager doing things correctly
Sure, but the point is you can query what the package manager has done.
> There's plenty of linux packages that creates files during operation in their designated /var/log/xxx /var/db/xxx /etc/xxx /home/xxx/ directories that you're not able to query using the package manager.
That's half true. You can query that /var/db/xxx and /var/log/xxx has been created by the package manager and often the directories (and their contents) will be owned by the user which the daemon runs under.
However I do agree with the point regarding your $HOME directory and actually made that point myself:
> Of course you still have the problem of the software writing files during its operation but that should be limited to $HOME (on POSIX systems) or any path that is writable by the owner / group of the user that application runs as (which should be limited even if it’s a system service).
As an aside, you can also query what files a particular application has open. In fact there are a few ways to do this from querying the /proc/$PID directory through to tools like `lsof`.