Debian Developers - Asking Debconf questions about database data

Author

Asking Debconf questions about database data

Philipp Kern

2005-08-06, 7:50 am

Dear Debian fellows,

what's the common practise if a package gets purged and depends on
user-supplied data in a database? In this case these are DNS zones (it's
about `mydns-mysql'). Currently there is a Debconf question in postrm,
which is definitely wrong because I cannot rely on Debconf being
installed at purge time. So I wanted to move it to prerm, but then I
don't know if the package is really purged.

Should one ask such a question at all? And if so, upon installation? I
personally feel that it should be presented on removal if at all
possible because then the user really knows what he wants to do. The
policy itself is about removing all configuration files on purge, but
does this include user data like supplied DNS records?

I noticed that BIND won't delete /etc/bind, if this is considered as a
``default'' location for zone files anyway. It uses rmdir which would
refuse to delete a directory which still contains files. The opinions on
what you need to delete on purge seem to be quite different, so I would
like to try to reach a consensus about this.

Kind regards,
Philipp Kern

Andreas Metzler

2005-08-06, 7:50 am

Philipp Kern <phil@philkern.de> wrote:
> what's the common practise if a package gets purged and depends on
> user-supplied data in a database? In this case these are DNS zones (it's
> about `mydns-mysql'). Currently there is a Debconf question in postrm,
> which is definitely wrong because I cannot rely on Debconf being
> installed at purge time.
[...]

Hello,
nowadays debconf is the canonical way to ask questions (policy
3.10.1), so I think it is ok to
a) ask with debconf in postrm purge if debconf is available
b) take the safe way out and do not delete the data otherwise.

Prompting manually using read if debconf is not available would be
perfect but personally I would not bother with that unless the
question is one of life and death.
cu andreas
--
"See, I told you they'd listen to Reason," [SPOILER] Svfurlr fnlf,
fuhggvat qbja gur juveyvat tha.
Neal Stephenson in "Snow Crash"
http://downhill.aus.cc/

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

Russ Allbery

2005-08-06, 5:51 pm

Philipp Kern <phil@philkern.de> writes:

> what's the common practise if a package gets purged and depends on
> user-supplied data in a database? In this case these are DNS zones (it's
> about `mydns-mysql'). Currently there is a Debconf question in postrm,
> which is definitely wrong because I cannot rely on Debconf being
> installed at purge time. So I wanted to move it to prerm, but then I
> don't know if the package is really purged.

> Should one ask such a question at all? And if so, upon installation? I
> personally feel that it should be presented on removal if at all
> possible because then the user really knows what he wants to do. The
> policy itself is about removing all configuration files on purge, but
> does this include user data like supplied DNS records?

Both PostgreSQL and the MIT Kerberos KDC (following PostgreSQL) ask the
question on installation with debconf.

--
Russ Allbery (rra@stanford.edu) <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

sean finney

2005-08-06, 8:47 pm

hi phillip,

On Sat, Aug 06, 2005 at 01:08:57PM +0200, Philipp Kern wrote:
> what's the common practise if a package gets purged and depends on
> user-supplied data in a database? In this case these are DNS zones (it's
> about `mydns-mysql'). Currently there is a Debconf question in postrm,
> which is definitely wrong because I cannot rely on Debconf being
> installed at purge time. So I wanted to move it to prerm, but then I
> don't know if the package is really purged.
>
> Should one ask such a question at all? And if so, upon installation? I
> personally feel that it should be presented on removal if at all
> possible because then the user really knows what he wants to do. The
> policy itself is about removing all configuration files on purge, but
> does this include user data like supplied DNS records?

i think it's kind of pointless to ask such a question at install time.
because Debian Is Not A Registry(tm) you have no guarantee that the
debconf responses won't be nuked off before the package is removed
anyway.

i think the best thing to do is to default to not removing the data, and
then at either removal or purge time *try* to ask via debconf, and only
if the question is successfully asked and positively responded should
you remove the data.

i touch on this in the "best practices for database applications" draft
i've been working on[1], but it's currently one of the points left open for
further discussion. if you feel like condensing the general consensus
into a paragraph or two to go into this document, i'd be appreciative.

sean

--
[1] http://people.debian.org/~seanius/p...app-policy.html

Henning Makholm

2005-08-07, 5:53 pm

Scripsit sean finney <seanius@debian.org>

> i think it's kind of pointless to ask such a question at install time.
> because Debian Is Not A Registry(tm)

And supposedly debconf isn't one either :-)

> you have no guarantee that the debconf responses won't be nuked off
> before the package is removed anyway.

It is at least conceivable for the postinst to actively store the
reply in an appropriate file in /etc which the postrm later reads.

Not that I think this would make much sense UI-wise anyhow.

--
Henning Makholm "I have seen men with a *fraction* of
your trauma pray to their deity for death's
release. And when death doesn't arrive immediately,
they reject their deity and begin to beg to another."

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

Anthony DeRobertis

2005-08-07, 5:53 pm

Henning Makholm wrote:

> It is at least conceivable for the postinst to actively store the
> reply in an appropriate file in /etc which the postrm later reads.
>
> Not that I think this would make much sense UI-wise anyhow.

Please, please don't do this! Consider what happens when the user
installs the package:

When this package is purged, do you want to delete all the
associated databases? (Y/n)

How's he to know? He's just installing it, doesn't yet know what is
stored there --- or, quite possibly, if he'll even use the package
(could just be installing it to see what it is, or to compare several
solutions). So he might say "yeah, I'm just playing around, sure. Y."

Now, a year later, after using it for a while, he purges it. Ooops. That
'yeah, whatever' last year just deleted his data.

BTW: Do you really even need to ask? Couldn't you just tell the admin,
if you want to delete your data, run dropdb foo? There is a small, but
certainly nonzero, risk of accidental deletion every time you ask. I
imagine that risk increases if, e.g., the admin is having to read a
foreign language (English) which he doesn't know too well.

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

Russ Allbery

2005-08-07, 5:53 pm

Anthony DeRobertis <anthony@derobert.net> writes:

> BTW: Do you really even need to ask? Couldn't you just tell the admin,
> if you want to delete your data, run dropdb foo? There is a small, but
> certainly nonzero, risk of accidental deletion every time you ask. I
> imagine that risk increases if, e.g., the admin is having to read a
> foreign language (English) which he doesn't know too well.

When one does that, people file bugs complaining that the package doesn't
remove all of the data it generates on installation.

As co-maintainer of one of the affected packages, I'm quite happy to go
along with the general consensus, since I don't really care. There seemed
to be a dislike of debconf questions in prerm and there was some precedent
for asking this sort of question in postinst, so that's what I've
currently gone with. It's not a great solution, and I'm happy to change
if someone else has a better idea.

--
Russ Allbery (rra@stanford.edu) <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

sean finney

2005-08-07, 5:53 pm

On Sun, Aug 07, 2005 at 02:35:59PM -0700, Russ Allbery wrote:
> When one does that, people file bugs complaining that the package doesn't
> remove all of the data it generates on installation.

there's a similar problem with logfiles too, and there have been quite
drawn out discussions in which both sides stated a pretty good case for
why it's good to leave/remove the files.

> As co-maintainer of one of the affected packages, I'm quite happy to go
> along with the general consensus, since I don't really care. There seemed
> to be a dislike of debconf questions in prerm and there was some precedent
> for asking this sort of question in postinst, so that's what I've
> currently gone with. It's not a great solution, and I'm happy to change
> if someone else has a better idea.

i don't think asking in the prerm is so bad, as long as you don't mind
dropping the data during removal as well as purges.

sean

--

Joey Hess

2005-08-08, 2:51 am

Russ Allbery wrote:
> As co-maintainer of one of the affected packages, I'm quite happy to go
> along with the general consensus, since I don't really care. There seemed
> to be a dislike of debconf questions in prerm and there was some precedent
> for asking this sort of question in postinst, so that's what I've
> currently gone with. It's not a great solution, and I'm happy to change
> if someone else has a better idea.

I don't see any problem with using debconf in the postrm purge in this
case. Debconf is designed to support it. You only have to make sure it's
installed at that point and fall back to some reasonable behavior in
case it's been removed.

(Actually, since its priority was recently updated to required, it's by
definition something nobody can sanely remove, but I'm not sure how I
feel about that yet.)

--
see shy jo

Anthony DeRobertis

2005-08-08, 2:51 am

Russ Allbery wrote:

> When one does that, people file bugs complaining that the package doesn't
> remove all of the data it generates on installation.

>
> [...] It's not a great solution, and I'm happy to change
> if someone else has a better idea.

Well, I think the real answer is that just like files on the filesystem,
databases need to be tracked by some sort of package manager. This
database manager would then be the single place to configure removal
behavior and manage databases in use by packages.

I'm certainly not asking you to write said database manager, though!

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