Re: [gentoo-portage-dev] Conary

[andrea ferraris <andrea_ferraris@libero.it>]

Paul de Vrieze wrote:
> On Sunday 24 October 2004 05:18, Ed Grimm wrote:
> 
>>Excluding program directories (for example, /etc/init.d), all changes to
>>existing /etc files should compensate for changes that the local
>>administrator has made.  For example, when upgrading a configuration
>>file, the new version should, as much as possible, retain the changes
>>that the local administrator has made.  When the ext3 filesystem tools
>>add a new option, any attempts to update /etc/fstab should ignore any
>>partitions that aren't ext3.  It should not add any partitions that it
>>feels are missing, either due to having ignored a reiserfs partition or
>>due to that partition not being there.  It should not alter any swap
>>partitions that haven't been modified according to a change the ext3
>>maintainer previously saw - it's possible it may have not been installed
>>here, it's possible the administrator backed it out.  It should NEVER
>>try to change the partition type (for example, from ext3 to xfs, like it
>>currently wants to do.)
> 
> 
> This is what dispatch-conf will do if you give it time to work. For 
> dispatch-conf to work you need to initialise it first. It works with 
> three-way diffs, so without a reference (which gets created the first time a 
> config file is updated with dispatch-conf) it doesn't work. For the rest, I 
> suggest you write up a patch to dispatch-conf to allow it to ignore certain 
> files. However it normally works quite well with fstab as the default one 
> hardly changes, and you'd want to know about those changes anyway.

Thx to you and other kind replying people >

I don't made yet my homeworks (studying dispatch-conf), so I was 
replying to Ed (with congrats), saying that was needed a 3 time diff.
I think that could be more convenient the dispatch-conf way, but 
conceptually the creation of a reference is not mandatory. It's enough a 
diff between the actually installed and modified file and the original 
one of that version, since the system know which is the version of the 
original one. Then it knows which are the original lines that 
disappeared or changed and at that point it could delete such lines (or 
those that substitute them) from the new standard cfg file and merge 
only the remaining diffs and in any case it shouldn't never substitute 
custom changes with standard in cfg files. Then it could not be bad one 
comment line at the beginning of new std cfg file where is written what 
changed and why (I know that for the developers could be annoying, but 
it should not take more than 1-2 minutes).

>>If people are interested, I could potentially write a tutorial on
>>methods one could utilize to perform such functions.  Note that this
>>would be written to writing the code in perl, as I don't know python
>>well, and it doesn't feel natural to me.
 >
 >
 > Well, go ahead
 >

There are no problem, I know neither python neither perl, so I'm the 
perfect candidate to translate your perl script in python ;-) because 
I'd like to learn python.
Anyway I know awk.

Andrea

P.S.: I'd like that someone for curiosity studied Conary to see what and 
how can be ported to gentoo portage, but I seen that my attempt has not 
been a very big success ;-), so maybe in my spare time, I'll try to do 
such thing myself and report here the results in the hope that you can 
teach me some about portage.

--
gentoo-portage-dev@gentoo.org mailing list