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 01-19-2008, 12:37 PM
Roger Leigh
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

Hi folks,

I noticed earlier today that many packages are creating copies of
conffiles in their maintainer scripts with the extension ".dpkg-bak",
which is not an extension used or removed by dpkg:

% grep EXT lib/dpkg.h
#define DEBEXT ".deb"
#define OLDDBEXT "-old"
#define NEWDBEXT "-new"
#define REMOVECONFFEXTS "~", ".bak", "%",
#define DPKGTEMPEXT ".dpkg-tmp"
#define DPKGNEWEXT ".dpkg-new"
#define DPKGOLDEXT ".dpkg-old"
#define DPKGDISTEXT ".dpkg-dist"
#define REASSEMBLETMP "reassemble" DEBEXT

A lot of scripts are copying the rm_conffile script from
http://wiki.debian.org/DpkgConffileHandling which adds a .dpkg-bak
suffix to old conffiles.

Are such names allowed? Why can't .dpkg-old be used instead?

If so, this is going to cause problems with programs like run-parts(1)
which do not take this case into account when excluding dpkg conffile
cruft, and so will run or read files which they should not use.

If this is not permitted behaviour, could we add a lintian check?

If it is permitted behavour, can run-parts and the dpkg documentation be
updated to match this and document its use, respectively?

A check on the packages in the lintian lab on gluck shows quite a lot of
matches. If this is truly buggy, I'd like to mass file bugs to fix this
issue.


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2008, 08:32 AM
Petter Reinholdtsen
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

[Roger Leigh]
> A lot of scripts are copying the rm_conffile script from
> http://wiki.debian.org/DpkgConffileHandling which adds a .dpkg-bak
> suffix to old conffiles.
>
> Are such names allowed? Why can't .dpkg-old be used instead?

I just noticed that when I rewrote the conffile removal code in
initscripts recently, I copied code from
http://wiki.debian.org/DpkgConffileHandling and accidently replaced
the code that created *.dpkg-old files with code that would create
*.dpkg-bak. I will change this back in initscripts. I would
recommend that someone fix the wiki page to use *.dpkg-old as well.

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2008, 01:10 PM
Michael Biebl
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

Roger Leigh wrote:

Hi folks,

I noticed earlier today that many packages are creating copies of
conffiles in their maintainer scripts with the extension ".dpkg-bak",
which is not an extension used or removed by dpkg:


Say you name the file /etc/foo.dpkg-old instead of /etc/foo.dpkg-bak.
dpkg won't remove this file on purge either, as it doesn't have any
reference anymore on /etc/foo.


So there is basically no difference here between using *.dpkg-bak or
*.dpkg-old. To really cleanup up the backup file, you'd have to do that
in postrm/purge. I agree, the wiki should be updated in that regard.


The advantage imho of using *.dpkg-bak is, that you can differentiate
which files were created by dpkg and which one by the maintainer scripts.


Maybe it would be a good idea to write a debhelper script (say
dh_obsolete), which would create the necessary maintainer scripts.
This would avoid to copy the scripts from
http://wiki.debian.org/DpkgConffileHandling over and over again.


Regarding run-parts: There is no problem afaik. I quickly tried this:

# mkdir test
# touch test/foo
# touch test/foo.dpkg-old
# touch test/foo.dpkg-bak
# run-parts --list test
test/foo

Cheers,
Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
 
Old 01-20-2008, 02:30 PM
Roger Leigh
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

On Sun, Jan 20, 2008 at 03:10:38PM +0100, Michael Biebl wrote:
> Roger Leigh wrote:
>> Hi folks,
>>
>> I noticed earlier today that many packages are creating copies of
>> conffiles in their maintainer scripts with the extension ".dpkg-bak",
>> which is not an extension used or removed by dpkg:
>
> Say you name the file /etc/foo.dpkg-old instead of /etc/foo.dpkg-bak.
> dpkg won't remove this file on purge either, as it doesn't have any
> reference anymore on /etc/foo.

OK.

> So there is basically no difference here between using *.dpkg-bak or
> *.dpkg-old. To really cleanup up the backup file, you'd have to do that in
> postrm/purge. I agree, the wiki should be updated in that regard.

Ack.

> The advantage imho of using *.dpkg-bak is, that you can differentiate which
> files were created by dpkg and which one by the maintainer scripts.

True. I have no objection to .dpkg-bak in principle--it would just be
nice if it was made "official". Currently some scripts are infringing
on the .dpkg-(old|new|dist|tmp)$ namespace, where .dpkg-bak might be
more appropriate, but it would be nice to have some clear guidelines on
which names are appropriate for maintainer scripts to use.

> Maybe it would be a good idea to write a debhelper script (say
> dh_obsolete), which would create the necessary maintainer scripts.
> This would avoid to copy the scripts from
> http://wiki.debian.org/DpkgConffileHandling over and over again.

This would be very useful. It could also robustly add all the
necessary bits to preinst/postrm, so long as you just told it which
version you removed it. Currently it's all too easy to make a
mistake, particularly if you want to handle aborted installs and
downgrades.

> Regarding run-parts: There is no problem afaik. I quickly tried this:
>
> # mkdir test
> # touch test/foo
> # touch test/foo.dpkg-old
> # touch test/foo.dpkg-bak
> # run-parts --list test
> test/foo

This does appear to be the case (I also tested it). But, it doesn't
match the documentation, nor the source!

run-parts.c:
regcomp(&excsre, "^[a-z0-9-].*dpkg-(old|dist|new|tmp)$",


Regards,
Roger

--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2008, 02:44 PM
Adeodato Simó
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

* Roger Leigh [Sun, 20 Jan 2008 15:30:43 +0000]:

> On Sun, Jan 20, 2008 at 03:10:38PM +0100, Michael Biebl wrote:
> > Regarding run-parts: There is no problem afaik. I quickly tried this:

> > # mkdir test
> > # touch test/foo
> > # touch test/foo.dpkg-old
> > # touch test/foo.dpkg-bak
> > # run-parts --list test
> > test/foo

> This does appear to be the case (I also tested it). But, it doesn't
> match the documentation, nor the source!

> run-parts.c:
> regcomp(&excsre, "^[a-z0-9-].*dpkg-(old|dist|new|tmp)$",

By reading the manual page (and not the source), by *default* run-parts
does not run any file whose name contains a dot, so .dpkg-bak is ignored.

With the --lsbsysinit switch, dots are allowed (as in foo.bar-baz, not
as in foo.bar only, though), but in that case those .dpkg-* files are
purposedly ignored (presumably with the regex above).

In summary, `run-parts` is safe wrt .dpkg-bak, `run-parts --lsbsysinit`
is not.

Cheers,

--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org

We may not return the affection of those who like us, but we always
respect their good judgement.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2008, 04:54 PM
Joey Hess
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

Petter Reinholdtsen wrote:
> I just noticed that when I rewrote the conffile removal code in
> initscripts recently, I copied code from
> http://wiki.debian.org/DpkgConffileHandling and accidently replaced
> the code that created *.dpkg-old files with code that would create
> *.dpkg-bak. I will change this back in initscripts. I would
> recommend that someone fix the wiki page to use *.dpkg-old as well.

Note that there's also http://www.dpkg.org/dpkg/ConffileHandling, which
has the .dpkg-bak extension also, and has generally older versions of
the code that lintian will complain about.

Why are we copying shell functions off of wikis and embedding them into
our maintainer scripts instead of adding the code to Debian once in a
utility?

(I've considered putting this code in debhelper, but the way it's used
is not an especially good fit for debhelper.)

--
see shy jo
 
Old 01-20-2008, 05:22 PM
Clint Adams
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

On Sun, Jan 20, 2008 at 04:44:34PM +0100, Adeodato Simó wrote:
> In summary, `run-parts` is safe wrt .dpkg-bak, `run-parts --lsbsysinit`
> is not.

Easy enough to fix if need be.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2008, 05:39 PM
Michael Biebl
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

Joey Hess wrote:

Why are we copying shell functions off of wikis and embedding them into
our maintainer scripts instead of adding the code to Debian once in a
utility?


I'm all for this! The sad truth is, that currently a lot of maintainers
simply forget to handle conffiles removals/moves. So having a wiki page
to point at is better than nothing.



(I've considered putting this code in debhelper, but the way it's used
is not an especially good fit for debhelper.)


Why do you think, debhelper is not the correct place to handle this?
Imho it would be fairly easy to write a debhelper command for this.

Another way would be, to make dpkg smarter about such cases.
As you want to write a special utility for this, how would you hook this
up into the install/upgrade process? If you have to edit maintainer
scripts again, you haven't gained a lot imho.


Cheers,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
 
Old 01-20-2008, 07:50 PM
Petter Reinholdtsen
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

[Michael Biebl]
> Why do you think, debhelper is not the correct place to handle this?
> Imho it would be fairly easy to write a debhelper command for this.
> Another way would be, to make dpkg smarter about such cases. As you
> want to write a special utility for this, how would you hook this up
> into the install/upgrade process? If you have to edit maintainer
> scripts again, you haven't gained a lot imho.

What API should be provided? I assume the script name and the version
it was removed would be enough?

Something like 'dh_obsolete /etc/init/oldfile 1.0.0-1', perhaps? One
entry per file?

Happy hacking,
--
Petter Reinholdtsen


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 01-20-2008, 09:34 PM
David Nusinow
 
Default Incorrect use of dpkg conffile suffixes and lintian checks

On Sun, Jan 20, 2008 at 12:54:42PM -0500, Joey Hess wrote:
> Why are we copying shell functions off of wikis and embedding them into
> our maintainer scripts instead of adding the code to Debian once in a
> utility?
>
> (I've considered putting this code in debhelper, but the way it's used
> is not an especially good fit for debhelper.)

Indeed, the XSF is carrying around tons of shell functions that are
generally useful and so should go in to some sort of central package, but
there's nowhere to put them. Getting something like this started has been
on the backburner for me for a while. I'd happily contribute what we've got
to such a package, or help start one up.

- David Nusinow


--
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 03:56 AM.

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