FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 02-22-2009, 04:01 PM
Manoj Srivastava
 
Default ucf: Diversion of /u/b/ucf by etcgit

On Sun, Feb 22 2009, Vincent Danjean wrote:

> Manoj Srivastava wrote:
>> I think the correct thing for the wrapper to do is
>> a) change branch to the upstram_version_branch, and commit the new
>> upstream.
>> b) Change back to the local branch
>> c) run ucf and let the user do their thing (replace, not replace, edit,
>> whatever).
>> d) Commit the result to the local_changed_branch.
>
> I also think this would be a good think.
>
> But perhaps, ucf can be improved to detect this situation (perhaps a new
> option that etcgit add before calling the real ucf) and can propose a
> new way to resolve the confict :
> - use old conffile
> - use new conffile
> - see diff
> - try experimental 3 way merge
> - ...
> - merge with etcgit <- new option for the user

I'll be happy to review and accept a patch adding such a
command-line option and a run-hook invovation to ucf.

> If selected, the new option will run a callback provided by etcgit
> that will merge the corresponding branches with git.


Sounds good.

> You will need to discuss between you to define properly the
> interfaces.

> It is also possible to improve ucf to propose new generic ways of
> handling merges (and perhaps storing the original file and the
> resulted file) just by installing callback scripts.

You know where to file wishlist bugs. Adding run-hook calls to
parts of the ucf processing should be easy; specifying those hooks only
slightly more complex.

> Then etcgit or other similar packages will be able to install their
> hooks without messing with provides/conflicts/diversions/... of ucf

I am always open to feature requests (preferably with
patches). However, I do not now, and do not plan in the future, to
personally use etckeeper. I already have bit of my /etc in git, but I
only keep files I have invested some effort into modifying in git, and
I mainly care about the history of the file o disk, as opposed to
upstream versions of the configuration file -- and I ma happy with this
subset of etckeeper functionality.

Given that, and my unfamiliarity with etckeeper internals, these
enhancements to ucf won't happen without collaboration with people with
knowledge of, and motivation for, things like etckeeper.

manoj
--
"There is no snooze button on a cat who wants breakfast."-Unknown
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 04:09 PM
Jörg Sommer
 
Default ucf: Diversion of /u/b/ucf by etcgit

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.

> Also, there might be nothing shipped with the package. You can't
> "hook into apt-get" to get the file generated in the postinst -- since
> there might not _be_ a upstream version at all until the postinst is
> run.

You can with the Post-Invoke hook.

> I will consider adding a conflicts to the ucf package as well.

Are you contented, when I disable the wrapper and add an option so the
user can enable the wrapper if he likes or leave it if he dislikes?

Regards, Jörg.
--
Perfection is reached, not when there is no longer anything that can be
added, but when there is no longer anything to take away.
(Antoine de Saint‐Exupery)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 04:10 PM
Jörg Sommer
 
Default ucf: Diversion of /u/b/ucf by etcgit

Hi Steve,

Steve Langasek <vorlon@debian.org> wrote:
> On Sat, Feb 21, 2009 at 11:09:52PM +0000, Jörg Sommer wrote:
>> save_original
>> merge_with_current
>> export UCF_FORCE_CONFFOLD=1
>> ucf.etcgit "$@"
>
> So this will leave the ucf db with a horribly incorrect view

Which bit in ucf's database would become invalid?

Regards, Jörg.
--
Du hast keine Chance – also nutze sie.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 04:38 PM
Jrg Sommer
 
Default ucf: Diversion of /u/b/ucf by etcgit

Hi Frank,

Frank Kster <frank@debian.org> wrote:
> Jrg Sommer <joerg@alea.gnuu.de> wrote:
>
>> Right, but when I hook into apt-get, I can get the configuration file
>> shipped with the packages.
>
> You cannot, since the very purpose of ucf is to give dpkg-conffile-like
> behavior for configuration files *not* shipped in the package.

But I can get the files dpkg installs in /etc. That's enough for the
first step. I don't want to create an AI that does everything right. One
step after the other!

Regards, Jrg.
--
Nutze die Talente, die du hast. Die Wlder wren sehr still,
wenn nur die begabtesten Vgel sngen. (Henry van Dyke)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 08:20 PM
Manoj Srivastava
 
Default ucf: Diversion of /u/b/ucf by etcgit

On Sun, Feb 22 2009, Jrg Sommer wrote:

> Manoj Srivastava <srivasta@debian.org> wrote:
>> On Sat, Feb 21 2009, Jrg 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? I think this is a
show-stopper.

>> Also, there might be nothing shipped with the package. You can't
>> "hook into apt-get" to get the file generated in the postinst -- since
>> there might not _be_ a upstream version at all until the postinst is
>> run.

> You can with the Post-Invoke hook.

What will you get about the newly created file in the
post-invoke hook? By the time the post-invoke hook is called, the
file might be long gone -- and since ucf is being told to ignore the
new file, you have lost it.

>> I will consider adding a conflicts to the ucf package as well.
>
> Are you contented, when I disable the wrapper and add an option so the
> user can enable the wrapper if he likes or leave it if he dislikes?

If you are going to divert ucf, I'll add a conflicts.

If the end usr disables or diverts ucf locally, that is their
problem, we give the users flexibility to shoot themselves in the
foot. Please add a note that the wrapper is not supported by ucf,and
if they isntall the wrapper, all bugs about it will be
ignored/redirected to etckeeper.

manoj
--
Dead? No excuse for laying off work.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 08:22 PM
Manoj Srivastava
 
Default ucf: Diversion of /u/b/ucf by etcgit

On Sun, Feb 22 2009, Jrg Sommer wrote:

> Hi Frank,
>
> Frank Kster <frank@debian.org> wrote:
>> Jrg Sommer <joerg@alea.gnuu.de> wrote:
>>
>>> Right, but when I hook into apt-get, I can get the configuration file
>>> shipped with the packages.
>>
>> You cannot, since the very purpose of ucf is to give dpkg-conffile-like
>> behavior for configuration files *not* shipped in the package.
>
> But I can get the files dpkg installs in /etc. That's enough for the
> first step. I don't want to create an AI that does everything right. One
> step after the other!

No, dpkg installs _nothing_ in /etc for ucf related files -- so
this is a failure as a first step, for ucf controlled configuration
files. The configurations files are isntalled by ucf (and you propose
disabling even that). So far from an artificial intelligence, you have
accomplished what I would consider an RC bug (breaks unrelated packages
justification).


manoj

--
For every problem there is one solution which is simple, neat, and
wrong. Mencken
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 10:02 PM
Jrg Sommer
 
Default ucf: Diversion of /u/b/ucf by etcgit

Manoj Srivastava <srivasta@debian.org> wrote:
> On Sun, Feb 22 2009, Jrg Sommer wrote:
>> Manoj Srivastava <srivasta@debian.org> wrote:
>>> On Sat, Feb 21 2009, Jrg 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?

>>> Also, there might be nothing shipped with the package. You can't
>>> "hook into apt-get" to get the file generated in the postinst -- since
>>> there might not _be_ a upstream version at all until the postinst is
>>> run.
>
>> You can with the Post-Invoke hook.
>
> What will you get about the newly created file in the
> post-invoke hook?

The newly created file. I add it to the local branch to track the
changes. I can't tell the user where it comes from nor in which way his
file differs from the original, but it's in the tree. Nothing more.
That's the same etckeeper does for many versions. And did you get any
complains about your ucf acting wrong?

> By the time the post-invoke hook is called, the file might be long
> gone

Why should it be gone? If someone (dpkg, ucf, a update-somthing tool or a
maintainer script) puts a file underneath /etc, who should remove it?

> -- and since ucf is being told to ignore the new file, you have lost
> it.

I only tell ucf to not touch the file if I can get it in the wrapper. If
not the wrapper is invoked (or disabled), but the real ucf, I can't tell
it to not touch the new file.

>>> I will consider adding a conflicts to the ucf package as well.
>>
>> Are you contented, when I disable the wrapper and add an option so the
>> user can enable the wrapper if he likes or leave it if he dislikes?
>
> If you are going to divert ucf, I'll add a conflicts.

But then you force me to replace ucf what I don't want to do. I offered
the option to disable the wrapper by default and make everything works as
if the wrapper isn't there. What's the problem?

Bye, Jrg.
--
Damit das Mgliche entsteht, mu immer wieder das Unmgliche versucht
werden. (Hermann Hesse)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-22-2009, 10:14 PM
Jrg Sommer
 
Default ucf: Diversion of /u/b/ucf by etcgit

Manoj Srivastava <srivasta@debian.org> wrote:
> On Sun, Feb 22 2009, Jrg Sommer wrote:
>> Frank Kster <frank@debian.org> wrote:
>>> Jrg Sommer <joerg@alea.gnuu.de> wrote:
>>>
>>>> Right, but when I hook into apt-get, I can get the configuration file
>>>> shipped with the packages.
>>>
>>> You cannot, since the very purpose of ucf is to give dpkg-conffile-like
>>> behavior for configuration files *not* shipped in the package.
>>
>> But I can get the files dpkg installs in /etc. That's enough for the
>> first step. I don't want to create an AI that does everything right. One
>> step after the other!
>
> No, dpkg installs _nothing_ in /etc for ucf related files

Right, but your are mixing two different things. (1) I use the
hooks provided by apt to get the original files from the
package and the updated files after apt has done everything.
This has nothing to do with the ucf wrapper!

(2) And I use a wrapper for ucf to get the original file
supplied by the maintainer script.

> The configurations files are isntalled by ucf (and you propose
> disabling even that). So far from an artificial intelligence, you have
> accomplished what I would consider an RC bug (breaks unrelated
> packages justification).

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 "$@"

Bye, Jrg.
--
NetBSD ist fr Frauen: es luft auf Waschmaschinen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 04:45 AM
Manoj Srivastava
 
Default ucf: Diversion of /u/b/ucf by etcgit

On Sun, Feb 22 2009, Jrg Sommer wrote:

> Manoj Srivastava <srivasta@debian.org> wrote:
>> On Sun, Feb 22 2009, Jrg Sommer wrote:
>>> Manoj Srivastava <srivasta@debian.org> wrote:
>>>> On Sat, Feb 21 2009, Jrg 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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-23-2009, 07:24 PM
Frank Kster
 
Default ucf: Diversion of /u/b/ucf by etcgit

Jrg Sommer <joerg@alea.gnuu.de> wrote:

>>> But I can get the files dpkg installs in /etc. That's enough for the
>>> first step. I don't want to create an AI that does everything right. One
>>> step after the other!
>>
>> No, dpkg installs _nothing_ in /etc for ucf related files
>
> Right, but your are mixing two different things.

NO, you don't seem to understand what ucf is for, and is doing.

> (1) I use the
> hooks provided by apt to get the original files from the
> package

In other words, with ucf you get NOTHING, since there are no original
files in the package. They are only created temporarily while postinst
is run.

Regards, Frank
--
Frank Kster
Debian Developer (TeXLive)
VCD Aschaffenburg-Miltenberg, ADFC Miltenberg
B90/Grne KV Miltenberg


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 12:53 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org