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