Re: RFC: common database policy/infrastracture
On Thu, 16 Dec 2004, sean finney wrote:
but something to point out: dbconfig-common already performs the
administrative actions needed to set up the database and database user
in the first place, so does your package even need the admin password?
The applilcation I want to package comes with a quite complex bootstrap
script which does *all* setup (including creating the database and
adding an admin account). So what we could do here:
1. From a Debian point of view provide an option for debconf which
just tells postinst not to create the database etc, because
the bootstrap script would take over this job.
Just provide the data which are needed in a defined interface
instead.
2. From the application point of view I could ask people to
include an option which prevents the bootstrap script from
doing the work which is just done. I guess this is no big deal
for the very responsive authors.
take a look at 0.8 :)
URL?
I hope you would announce new versions or just move the package to
experimental to keep people informed.
this was the plan all along, but i had to start
with what i knew. also, i discovered that you can't reliably use
$0 in the maintainer scripts because when a package is first
preconfigured before being unpacked the filename doesn't follow
the same naming scheme.
Sure. The use of $0 was just to make things clear as a sketch. The
implementation has to be a bit more precise...
but now there are subscripts for
the supported mysql and pgsql database types, and a larger common
type (which will eventually support applications that support
multiple db types):
mini-me[~]10:28:00$ ls /usr/share/dbconfig-common/dpkg/
common postinst postrm.mysql preinst.pgsql
config postinst.mysql postrm.pgsql prerm
config.mysql postinst.pgsql preinst prerm.mysql
config.pgsql postrm preinst.mysql prerm.pgsql
While this is only cosmetics I would prefer storing the database
specific stuff in separate directories. If we will have more databases
it would be more easy to read.
for the admin pass, it should be configurable globally whether or not
the admin password is stored at all.
This would be nice.
for the user password, it will
have to be stored in a file somewhere anyway for whatever application
uses the database, so i'm not too concerned about that.
No problem with that. If the package maintainer thinks it has to be
deleted afterwards - there will be a way to do so ...
i'm not against providing a way around that, however, if there really
is a situation in which you wouldn't need the password.
If all else fails: dd if=/dev/zero of=/dev/hda ;-)
i believe that when policy speaks of configuration it is in fact
speaking of the postinst script. the .config script is usually
referred to as "pre-configuration". with pre-configuration, it is
true that you can't rely on any dependencies being met, but touching
files in the .config script is generally a bad practice, and i don't do
anything other than ask debconf questions in the config script.
Well, if this is really the case than it would save a certain amount
of time for me. While I think this is a perfectly reasonable
requirement I remember times were this was not the case and I had
trouble to work around this.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: