RPM roadmapping

Theodore Papadopoulo Theodore.Papadopoulo at sophia.inria.fr
Mon Jul 30 11:31:08 UTC 2007

Arthur Pemberton wrote:
> On 7/30/07, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
>> /me would like something like this as well, so I'm jumping in here
>> On 30.07.2007 11:38, Arthur Pemberton wrote:
>>> On 7/30/07, Matthias Saou
>>> <thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net>
>>> wrote:
>>>> Panu Matilainen wrote :
>>>>> [...] So: what have you always wanted to do
>>>>> with rpm, but wasn't able to? Or the other way around: what you always
>>>>> wished rpm would do for you? What always annoyed you out of your mind?
>>>> After reading some of the other posts, I remembered something that has
>>>> often come up, which I would use extensively if it existed :
>>>> Some automatic cache/copies of all %config files installed, with all
>>>> untouched versions always available. This would be very useful with
>>>> some simple tool to diff the current files(s) wit the backup(s), as
>>>> well as list all locally changed %config files. A sysadmin's dream come
>>>> true :-)
>>> To be clear, are you thinking of a something like
>>> cp *.conf /etc/backupconfs?
>> For me the proper solution would be: (1) let RPM (or the packages
>> itself) ship a copy of all %config files somewhere in a place where they
>> are safe and don't get modified. (2) When the user edited a %config file
>> then let rpm on package update make a copy of the %config file from the
>> *old* package into another save place
>> Why that you ask? Simple, that way I can diff my current config file
>> against the modified one it is based on (the one created in (2) above).
>> Then I can take the current config file (the one from (1) above), copy
>> it in place and (manually) apply the diff I created earlier.
>> CU
>> knurd
> Seems like a good idea to me. But considering that config files are
> relatively small, this would be best if done automatically.
Why not directly putting all the config files under a version control 

More information about the fedora-devel-list mailing list