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

Re: ucf: Diversion of /u/b/ucf by etcgit



On Sun, Feb 22 2009, Jörg Sommer wrote:

> Manoj Srivastava <srivasta@debian.org> wrote:
>> On Sun, Feb 22 2009, Jörg Sommer wrote:
>>> Manoj Srivastava <srivasta@debian.org> wrote:
>>>> On Sat, Feb 21 2009, Jörg Sommer wrote:
>>>>>
>>>>> Right, but when I hook into apt-get, I can get the configuration file
>>>>> shipped with the packages. But that has nothing to do with ucf.
>>>>
>>>>         What does "hook into apt-get" mean?
>>>
>>> I use the hooks Pre-Install-Pkgs and Post-Invoke as provided by apt-get.
>>
>>>>         What happens if I do a dpkg -i?
>>>
>>> Nothing. You have to update the branches by hand.
>>
>>         And yet you are proposing to divert ucf?
>
> What do you suggest should happen when you run dpkg -i? What
> should etcgit do?

        etcgit should work whether or not it was aptitude, synaptic,
 apt-get, or dpkg which was used to install the package.

        The part I am worried about is whether the wrapper allows ucf to
 do its job; namely, ask the use what they want to do with any changes
 in configuration files.  Based on your earlier email about calling ucf
 with FORCE_CONFOLD, that is not going to happen. 

 Have you changed your mind about
   a) using force_confold?
   b) merging the upstream branch into the local branch (without using
      the merge policy of ours)?

        If you have not, either one of these would, in my opinion, would
 be an unacceptable bug that breaks installations. Now, you have also
 talked about not installing the wrapper -- which would be fine. If
 there is no wrapper around ucf, or f the wrapper does not use h
 FORCE_CONFOLD, I think the package will work

        I can explain why merging upstream changes into the local branch
 (unless you use the --strategy=ours)[1]

        The rest of the email is about issues raised due to the fact
 that I believed you were talking about a wrapper that gutted ucf; if we
 are talking about no wrapper, or the wrapper not using FORCE_CONFOLD,
 we are fine. 

> But in this bug report you have to explain what broke. I please you,
> don't wait and tell it me now. Tell me what breaks when I divert ucf to
> ucf.etcgit and install this script as ucf:
>
> #!/bin/sh
>
> exec ucf.etcgit "$@"

        Aha. You got rid of the FORCE_CONFOLD, and you are not merging
 the upstream into the local branch. This will work.

[1]
,----[ Old upstream version ]
| # This can be A or B
| behaviour_type=A
| 
| # Other stuff
`----

,----[ User modified local config version ]
| # This can be A or B
| behaviour_type=B
| 
| # Other stuff
`----


,----[ New upstream version ]
| # This can be A or B
| behaviour_type=A
| 
| # Other stuff
| 
| # Do not leave these uncommented unless behaviour type is A
| Do_Type_A_Stuff=YES
`----

        If  changes from the upstream branch are applied to the local
 version, and not verified by a human; we will get a broken config.

        manoj
-- 
Truthful, adj.: Dumb and illiterate. Ambrose Bierce, "The Devil's
Dictionary"
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


Reply to: