On Sun, Dec 13, 2015 at 3:39 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:
Am 13.12.2015 um 21:22 schrieb Andrew Lutomirski:
> For the few cases that can't or won't comply, then having rpm
> (optionally?) make the originals available would be fantastic for
> system management
how many copies would you like to store in the rpm database and how to
access them in a useful manner
For my purposes, exactly 1 copy would be needed: the one contained in the currently installed packages, before any user modifications.
define "originals"
For me, I'd want the up-to-date one from the current version of the installed packages, not the initial state... just the up-to-date state as determined by the package maintainer. My main interest is finding what the user changed, to make it different from the packager's defaults.
when the system was installed versus current state?
worthless - most of my Fedora setups are from 2008
the current and the previous version?
well, you need to handle cases where a config file is unchanged but the
package is updated, that's the majority of all updates
honestly:
that all violates the unix principles one tool for one task and there
are tools available for config file management many years, people
interested just need to use them, "etckeeper" is integrated in dnf/yum
and makes a versioned "snapshot" of /etc before and after updates are
applied
For me, I just want to know what the user changed. (like how `rpm -V` shows that a file has been modified from the package version with an md5 check... but I want to know the content of those modifications). I'm not sure what the best tool for this task is, but I'm pretty sure etckeeper isn't it. rpm is already doing similar functionality, but not tracking the full files, only the md5 hashes. yum/dnf is also doing similar functionality when it creates *.rpmnew files, but only when the packager's version is updated... essentially I'd want *.rpmnew to be created every time (and left on the system, never being deleted) so it can be compared with the user version.
I'm not sure I agree that UNIX principles are to have one tool for one task. It is common for there to be many tools capable of achieving the same task. I think the principle is to have one task for each tool and to do that task well (in other words, tools shouldn't be bloated, but they can certainly have alternatives). But, that's not even what we're talking about here. At least, it's not what I'm talking about. What I'm talking about is: 1) trying to find the best tool for the task if it exists, 2) determining if a tool must be created, and 2) figuring out if features must be added to the underlying package management system to support those tools.
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
