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 04-25-2010, 01:18 AM
Neil Williams
 
Default When debconf is no longer required for a package...

Scenario:
A package has been using debconf successfully for a reasonable time
frame (including one stable release) but develops to a point where the
debconf questions are not only unused but potentially problematic and
could become a source of new bugs. The debconf questions, the
translations of those questions and the config script have all been
removed from the next version of the package (due for upload to
experimental soon). The debconf data and the files in /etc/ that were
used to store the values retrieved from debconf now need to be erased
*not upon purge but upon upgrade|configure*, whenever the old files
still exist. The old version of the package correctly uses a postrm
which only removes this data upon purge - so this doesn't get called
upon upgrade.

I would have thought that the code that used to do this task in the
old postrm could be migrated to a preinst or a postinst in the new
version of the package and tweaked to run under the relevant command. I
don't really mind which and I'm tending towards putting it into the
postinst because the package can configure with these files hanging
around, it just isn't particularly good to leave them around at runtime
- if only because it will confuse the user as so many other things
have changed in the package.

Maybe the solution is to change the postrm to act on upgrade as well as
purge (the old behaviour was just on purge) but then the unwanted files
hang around until every user has upgraded FROM the NEW version.

What I'd really like is a way for the new package to say "purge the old
version before installing this one" because the old version contains
all the necessary code to make a purge work correctly and the new
version wouldn't need any maintainer scripts at all. Maybe I need a
Conflicts: ?

I would have also thought that the package could drop dependencies on
debconf and ucf (which was used to manage the old files) as the
maintainer script can easily check if /usr/bin/ucf exists and whether
debconf exists etc. to purge the relevant data records before removing
the files themselves. (If debconf or ucf have been removed, the package
cannot do anything about the data that debconf|ucf should have deleted
upon their own removal.)

I'm getting lintian warnings:

W: libemdebian-tools-perl: postrm-does-not-purge-debconf
W: libemdebian-tools-perl: missing-debconf-dependency-for-preinst
W: libemdebian-tools-perl: maintainer-script-needs-depends-on-ucf
preinst

I had equivalent warnings when the instructions were in the postinst.

Yes, lintian can be wrong sometimes, but I thought I'd check the logic
here first.

Does the package have to retain debconf and/or ucf forever just because
it used it once? (Or keep the dependencies until the last version to
use the debconf data has gone from oldstable? That seems a tad
excessive and buggy.)

Does the package have to be modified to ignore the files even if they
still exist because the admin might have altered them? (Those
modifications cannot be allowed to have any effect on the new version
of the package because the old configuration is meaningless within the
model used by the new version, so "retaining local changes" has no
meaning in this context. The local changes are buggy by definition.)

Is this just a corner case that lintian doesn't catch? (Is it really so
rare that packages stop using debconf at some future version?) It's
roughly equivalent to a package moving from a database that needed
dbconfig-common support to some other backend (maybe a binary or simple
file based one) that didn't need any debconf configuration. I'd expect
this to have happened before.

The package concerned has changed radically in this new version - 50%
of the previous codebase has been removed and the whole package
operates according to a different model. I'm half tempted to change the
source package name and let it go through NEW again with a Conflicts:
Replaces: against all the old packages, but changing the binary package
names or conflicting against old versions of the same binary package
seemed wrong.

Suggestions?

--


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
 
Old 04-25-2010, 01:22 AM
Russ Allbery
 
Default When debconf is no longer required for a package...

Neil Williams <codehelp@debian.org> writes:

> Is this just a corner case that lintian doesn't catch? (Is it really so
> rare that packages stop using debconf at some future version?) It's
> roughly equivalent to a package moving from a database that needed
> dbconfig-common support to some other backend (maybe a binary or simple
> file based one) that didn't need any debconf configuration. I'd expect
> this to have happened before.

I have no strong opinions about the rest of your message, but so far as I
know, no one has ever mentioned this case to Lintian before and the
Lintian analysis code just doesn't anticipate it.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87sk6kfhqm.fsf@windlord.stanford.edu">http://lists.debian.org/87sk6kfhqm.fsf@windlord.stanford.edu
 
Old 04-25-2010, 01:50 AM
Joey Hess
 
Default When debconf is no longer required for a package...

Postinst:

#!/bin/sh
set -e
if some_version_test &&
[ -e /usr/share/debconf/confmodule ]; then
. /usr/share/debconf/confmodule
db_purge
fi

--
see shy jo
 
Old 04-25-2010, 08:16 AM
Neil Williams
 
Default When debconf is no longer required for a package...

On Sat, 24 Apr 2010 18:22:57 -0700
Russ Allbery <rra@debian.org> wrote:

> Neil Williams <codehelp@debian.org> writes:
>
> > Is this just a corner case that lintian doesn't catch? (Is it
> > really so rare that packages stop using debconf at some future
> > version?) It's roughly equivalent to a package moving from a
> > database that needed dbconfig-common support to some other backend
> > (maybe a binary or simple file based one) that didn't need any
> > debconf configuration. I'd expect this to have happened before.
>
> I have no strong opinions about the rest of your message, but so far
> as I know, no one has ever mentioned this case to Lintian before and
> the Lintian analysis code just doesn't anticipate it.

(I was far too verbose, I know. Should have waited until the morning,
too tired.)

Turns out that with a few tweaks to the postinst proposed by Joey,
lintian is happy, including with the ucf handling which was caught
initially.

Thanks, Joey.

postinst:
#/bin/sh

set -e

if dpkg --compare-versions "$2" lt-nl "2.2.0"; then
if [ -e /usr/share/debconf/confmodule ]; then
# Source debconf library.
. /usr/share/debconf/confmodule
# Remove my changes to the db.
db_purge
fi
# Remove the configuration files
if which ucf > /dev/null; then
ucf --purge /etc/apt/sources.list.d/emdebian.sources.list
ucf --purge /etc/emsource.conf
fi
if which ucfr > /dev/null; then
ucfr --purge emdebian-tools /etc/apt/sources.list.d/emdebian.sources.list
ucfr --purge emdebian-tools /etc/emsource.conf
fi
rm -f /etc/apt/sources.list.d/emdebian.sources.list
rm -f /etc/apt/sources.list.d/emdebian.sources.list.ucf-old
rm -f /etc/apt/sources.list.d/emdebian.sources.list.ucf-new
rm -f /etc/apt/sources.list.d/emdebian.sources.list.ucf-dist
rm -f /etc/emsource.conf
rm -f /etc/emsource.conf.ucf-old
rm -f /etc/emsource.conf.ucf-new
rm -f /etc/emsource.conf.ucf-dist
fi


--


Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
 

Thread Tools




All times are GMT. The time now is 11:00 AM.

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