Re: Easier %config management?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 14, 2015 at 11:22 AM Reindl Harald <h.reindl@xxxxxxxxxxxxx> wrote:


Am 14.12.2015 um 17:01 schrieb Christopher:
> On Sun, Dec 13, 2015 at 3:39 PM Reindl Harald <h.reindl@xxxxxxxxxxxxx
> 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

--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux