[Sks-devel] debian package tracking of the bdb version [was: Re: Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released]

[Daniel Kahn Gillmor]

Hi William--

On Sat 2016-09-03 10:10:13 -0400, William Hay wrote:
> 1.Thanks for the nice jessie-backports package.  

you're welcome!

> 2.AFAICT the package postinst performs a backup unless the file
> /var/lib/sks/berkeley_db.active is present and the contents match those
> of /usr/lib/sks/berkeley_db.txt in the package.  If the .active file is
> missing but the sks server is working then preventing the backup  may be
> possible by copying the .txt file to the .active file before upgrading
> if the old and new packages use the same database version.

that's right, but i really don't recommend that anyone fiddle with the
/var/lib/sks/berkeley_db.active file directly.  it should be
fully-managed by the package maintainer scripts, and as they say, if you
break it you get to keep both pieces ;)

> 3.Debian's file command seems to have a fair idea of what sort of file the 
> /var/lib/sks/DB/key file is (including a version number).  I wonder if
> the output of file could be used to determine if a database upgrade and 
> backup is needed rather than using a text file as a proxy (which seems to get
> lost rather easily).

If /var/lib/sks/berkeley_db.active is getting lost, i'd like to know
how!  If it's getting lost due to failures in the packaging or in a
common use case, that's a bug i'd very much like to fix.  I'd rather not
have to run /usr/bin/file on several different files and then write some
logic about how to deal with all of the different states that might
result from such a query, it seems pretty messy.  it also means that
we'd need to depend: (or pre-depend: depending on when it's used) on the
file package, which pulls in three more dependencies than it seems like
we ought to need.  In addition, going forward i doubt debian will ever
change the version of bdb, given the licensing debacle there.  so all
this code is likely to remain mostly unused in the future.

does my hesitation make sense?  My mind is possible to change if you
have stronger reasons (and esp. if they're accompanied by robust,
well-tested patches) but for now i'm inclined to leave things with the
berkeley_db.active file as a package-managed marker of the db version.

Thanks,

        --dkg

signature.asc
Description: PGP signature