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 12-05-2009, 02:47 PM
Patrick Schoenfeld
 
Default Should ucf be of priority required?

Hi,

when testing my packages with piuparts I noticed an inability of
our package management. Dpkg does not have support for management
of dynamically generated configuration files. Therefore some packages
now use ucf.

The basic usage is somewhat like
- Registering config files to ucf on installation
- Using it when configuring the package to merge configuration updates
and local changes
- Unregistering config files to ucf on purge

The crux is the last point. For a good reason postrm must not require
tools it depends on to be around when removing the package itself.
So the call of ucf looks something like that:

if which ucf >/dev/null; then
ucf --purge /etc/foo.conf
fi

That is okay, as long as ucf is around. But as soon as it isn't
the purge of a package is succesful while leaving modified files around.
So the effect is that a purge does not "remove everything".

Do we really want that? Should ucf be 'required' to avoid that?

Best Regards,
Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-05-2009, 03:56 PM
"brian m. carlson"
 
Default Should ucf be of priority required?

On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote:
> That is okay, as long as ucf is around. But as soon as it isn't
> the purge of a package is succesful while leaving modified files around.
> So the effect is that a purge does not "remove everything".
>
> Do we really want that? Should ucf be 'required' to avoid that?

ucf being priority required is not sufficient. It is still possible to
remove such a package (mawk is a good example) and therefore you would
still need to execute ucf conditionally. The only way around that is to
make ucf essential, and I don't think that's a good idea.

--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 713 440 7475 | http://crustytoothpaste.ath.cx/~bmc | My opinion only
OpenPGP: RSA v4 4096b 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187
 
Old 12-05-2009, 04:17 PM
Patrick Schoenfeld
 
Default Should ucf be of priority required?

On Sat, Dec 05, 2009 at 04:56:02PM +0000, brian m. carlson wrote:
> On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote:
> > That is okay, as long as ucf is around. But as soon as it isn't
> > the purge of a package is succesful while leaving modified files around.
> > So the effect is that a purge does not "remove everything".
> >
> > Do we really want that? Should ucf be 'required' to avoid that?
>
> ucf being priority required is not sufficient. It is still possible to
> remove such a package (mawk is a good example) and therefore you would
> still need to execute ucf conditionally.

You are right. My bad.

> The only way around that is to make ucf essential,
> and I don't think that's a good idea.

What speaks against it? Its basically a mini tool (Installed-Size: 260)
and not making it essential leads to the mentioned situations.

The only bad thing is, that it depends on a tool which is not essential
(debconf) and seems not to be able to render questions without debconf.

Or should we simply not care about packages modifying files (via
external tools) and not reverting those changes when beeing removed?

Regards,
Patrick


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-05-2009, 04:37 PM
Sven Joachim
 
Default Should ucf be of priority required?

On 2009-12-05 16:47 +0100, Patrick Schoenfeld wrote:

> Hi,
>
> when testing my packages with piuparts I noticed an inability of
> our package management. Dpkg does not have support for management
> of dynamically generated configuration files. Therefore some packages
> now use ucf.
>
> The basic usage is somewhat like
> - Registering config files to ucf on installation
> - Using it when configuring the package to merge configuration updates
> and local changes
> - Unregistering config files to ucf on purge

- Removing config files on purge

> The crux is the last point. For a good reason postrm must not require
> tools it depends on to be around when removing the package itself.
> So the call of ucf looks something like that:
>
> if which ucf >/dev/null; then
> ucf --purge /etc/foo.conf
> fi
>
> That is okay, as long as ucf is around. But as soon as it isn't
> the purge of a package is succesful while leaving modified files around.

It is the package's responsibility to remove those files, "ucf --purge"
does not do that, see ucf(1).

> So the effect is that a purge does not "remove everything".
>
> Do we really want that? Should ucf be 'required' to avoid that?

That would be no good.

Sven


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-05-2009, 04:43 PM
Manoj Srivastava
 
Default Should ucf be of priority required?

On Sat, Dec 05 2009, Patrick Schoenfeld wrote:

Short Answer: hell no.

Read below for why that would be a bad idea.

> when testing my packages with piuparts I noticed an inability of
> our package management. Dpkg does not have support for management
> of dynamically generated configuration files. Therefore some packages
> now use ucf.
>
> The basic usage is somewhat like
> - Registering config files to ucf on installation
> - Using it when configuring the package to merge configuration updates
> and local changes
> - Unregistering config files to ucf on purge

> The crux is the last point. For a good reason postrm must not require
> tools it depends on to be around when removing the package itself.
> So the call of ucf looks something like that:
>
> if which ucf >/dev/null; then
> ucf --purge /etc/foo.conf
> fi
>
> That is okay, as long as ucf is around.

And if ucf is not around, why bother cleaning up the ucf cache?
When ucf is purged, it will remove its own darned cache.

> But as soon as it isn't the purge of a package is succesful while
> leaving modified files around. So the effect is that a purge does not
> "remove everything".

This is where things break down. ucf --purge does not do what
you think it does, it by no means removes the configuration files. You
remove the configuration files, not ucf.

> Do we really want that? Should ucf be 'required' to avoid that?

What purpose would that serve?

manoj
--
Never try to teach a pig to sing; it wastes your time and it annoys the
pig.
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 12-05-2009, 04:44 PM
Manoj Srivastava
 
Default Should ucf be of priority required?

On Sat, Dec 05 2009, brian m. carlson wrote:

> On Sat, Dec 05, 2009 at 04:47:18PM +0100, Patrick Schoenfeld wrote:
>> That is okay, as long as ucf is around. But as soon as it isn't
>> the purge of a package is succesful while leaving modified files around.
>> So the effect is that a purge does not "remove everything".
>>
>> Do we really want that? Should ucf be 'required' to avoid that?
>
> ucf being priority required is not sufficient. It is still possible to
> remove such a package (mawk is a good example) and therefore you would
> still need to execute ucf conditionally. The only way around that is to
> make ucf essential, and I don't think that's a good idea.

Making a package essential in order to avoid a if clause in
postinsts is very likely too frivolous a reason to pass muster, yes.

manoj
--
The Constitution may not be perfect, but it's a lot better than what
we've got!
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 12-05-2009, 05:16 PM
Daniel Baumann
 
Default Should ucf be of priority required?

Patrick Schoenfeld wrote:

So the call of ucf looks something like that:

if which ucf >/dev/null; then
ucf --purge /etc/foo.conf
fi


no, the correct one is:

if which ucf >/dev/null; then
$whatever_ucf_command /etc/foo.conf
else
rm -f /etc/foo.conf
fi

--
Address: Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email: daniel.baumann@panthera-systems.net
Internet: http://people.panthera-systems.net/~daniel-baumann/


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-05-2009, 05:23 PM
Philipp Kern
 
Default Should ucf be of priority required?

On 2009-12-05, Daniel Baumann <daniel@debian.org> wrote:
> Patrick Schoenfeld wrote:
>> So the call of ucf looks something like that:
>>
>> if which ucf >/dev/null; then
>> ucf --purge /etc/foo.conf
>> fi
>
> no, the correct one is:
>
> if which ucf >/dev/null; then
> $whatever_ucf_command /etc/foo.conf
> else
> rm -f /etc/foo.conf
> fi
>

-p, --purge
Removes all vestiges of the file from the state hashfile. [...]
Note: ucf does not actually touch the file on disk in this operation, so
any file removals are still the responsibility of the calling package.

See man ucf.

Kind regards,
Philipp kern



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-05-2009, 07:39 PM
Steve Langasek
 
Default Should ucf be of priority required?

On Sat, Dec 05, 2009 at 06:17:20PM +0100, Patrick Schoenfeld wrote:
> > ucf being priority required is not sufficient. It is still possible to
> > remove such a package (mawk is a good example) and therefore you would
> > still need to execute ucf conditionally.

> You are right. My bad.

> > The only way around that is to make ucf essential,
> > and I don't think that's a good idea.

> What speaks against it? Its basically a mini tool (Installed-Size: 260)
> and not making it essential leads to the mentioned situations.

> The only bad thing is, that it depends on a tool which is not essential
> (debconf) and seems not to be able to render questions without debconf.

> Or should we simply not care about packages modifying files (via
> external tools) and not reverting those changes when beeing removed?

Aside from the misunderstanding about how ucf works in practice, this
doesn't belong as Essential because Essential exists for two reasons:

- to resolve dependency loops in the core system that otherwise could not
be solved
- to declare the minimal set of functionality that must be available and
usable on the system at all times, even when not configured

There's no reason that ucf *should* fall under either of these rules; so
even if ucf /didn't/ work the way it does, the right solution here would be
to fix it so that it did, not to add it to Essential.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
 
Old 12-05-2009, 07:48 PM
Michael Banck
 
Default Should ucf be of priority required?

On Sat, Dec 05, 2009 at 12:39:28PM -0800, Steve Langasek wrote:
> the right solution here would be to fix it so that it did, not to add
> it to Essential.

On a side note, I thought the right solution was to integrate the ucf
functionality into dpkg. Any update on this, or was this just wishful
thinking on my part?


Michael


--
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 04:12 PM.

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