On Mon, Dec 14, 2015 at 11:22 AM Reindl Harald <h.rei...@thelounge.net> wrote:
> > > Am 14.12.2015 um 17:01 schrieb Christopher: > > On Sun, Dec 13, 2015 at 3:39 PM Reindl Harald <h.rei...@thelounge.net > > 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 > > > > For me, I just want to know what the user changed > > what you propose can't work for that because you only compare the > *current users* version with the *current package* version > > Yes, that's all I want. > that is a naive approach > > Yes, but the naive approach satisfies my use case. Others may have more needs, but this is all I need. As an SA, I don't need to track the full history of the packages (at least, not on every user's machine), and there's easier ways to get that anyway (look in cgit and/or upstream VCS). I just need to periodically check in on what the user has tampered with (for example, when they come to me for assistance when something is broken), or to periodically back up or audit their changes. > i modified my "httpd.conf" based on Apache 2.2 years ago, as Fedora > swicthed to Apache 2.4 your approach would have compared a customized > Apache 2.2 version with a Fedora 2.4 version > > But, that's precisely what I want to do.... I want to know which fields in the current configuration could possibly have introduced a breakage I see... or which changes I need to make from a clean installation to get a user back to the state they wanted. > the same happens to anything which has large changes over time > > the moment when config formats are changing is the one where it starts > to become interesting and at that moment is completly wortless to > compare different generations of a config file without the full history > > I would disagree that it's completely worthless, but I agree that it's more difficult. But, this is where I go to the docs anyway: "K1 did F in version V1, but K2 does F in version V2". I would never migrate configs based on history; I do it based on the docs. > what you *really* would need to compare at *that moment* is your changes > years ago based on the dist-version of the config file at the same moment > > No, I don't... not for my use case. I want to know what differences are to either fix a problem a user is having (when a default config works), or to back up those differences so I can reinstall a clean system and get a user back to the state they had before. > that's nothing you can or should try to cover with rpm - try to solve > this with 1 or 2 limited copies would fail after dist-upgrades as i have > already said > > I agree... I don't think rpm should do all that. But, again, that's not what I need, nor what I'm suggesting rpm be able to do. compare two versions is worthless, you need at least three to *get a > context* > > * previous dist version - CAUTION > * your current version > * now to install/installed dist-version > > which previous dist-version owul dbe helpful depends, the most > interesting one is that from where user changes derived and to answer > that question you need more data than one copy because form the first > change on the *users version* will always differ, but from which distro > state did that happen > > <http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org>
-- devel mailing list devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
