On Thu, 2 Dec 2004, sean finney wrote:
most of the script stuff could be shared in between the two, yeah. i
designed the system such that it could eventually handle supporting
multiple database types, as well as packages that support multiple
database types themselves. then, i proceeded to start with what i know :)
currently, i'm using code from wwwconfig-common for doing the actual
db stuff, and there is pgsql support in that package, so i don't think
implementing pgsql support would be initially too hard.
Well, my question is basically: Should I just copy and search+replace
the mysql stuff to pgsql (which is error prone for future changes which
are quite possible) Or should we do something like inserting a variable
in all these scripts for the database and use a parameter or even do
something like
<script>.any
ln -s <script>.any <script>.mysql
ln -s <script>.any <script>.pgsql
ln -s <script>.any <script>.<whatever>
and obtain the database from $0 ?
so dbconfig-common provides two hooks for running
install/bootstrap/upgrade code. the first is just a plain sql file,
the second is a shell script that can effectively do anything. i
have not tested the latter at all, but have written code that i
think will work. the dbconfig-common-using.html document provides
the details. however, in both cases i don't have it set up to run as
the database administrator, that was really a design choice and not a
limitation, and if it turns out it's not worth it i could have it run
as administrator instead.
I see no problem in providing a script there which runs as root and
does a
su - <dbadmin> real_bootstrap_script
db_get gnumed/pgsql/admin-pass
insert_passwd_into_temporary_config_file $RET
bootstrap_gnumed_database --config temporary_config_file
rm temporary_config_file
My problem is now: How to address gnumed/pgsql/admin-pass in
your dbconfig-common framework?
the big question in my mind is what about the package needs
administrative access? this might stem from my not understanding
differences between mysql and postgresql.
Well, I guess this might be solved by "su" as mentioned above, but
my problem is, who to access the values the user have input in the
debconf questions? I need to know some of these values in the
script.
Moreover I have a further problem: The database consists of a basic
server and than there are some tables for different locales which I
wnt to provide in different packages (because you need only one locale
package, for instance either for Germany or for Australia but not both).
The problem is, that I have to ensure that the common server is installed
*first* before any locale server would be installed (because the locale
server relay on the existance of certain tables.
However, I can not relay on the fact that dependent packages are installed
in a certain sequence thus it might occure that the postinst ot the
common server was not finished when the locale server postinst is running.
My idea for a solution in the locale postinst was:
1. check whether common server is existant (and has the right version)
2. a) if yes run locale bootstrap script
b) if no, touch /var/run/<packagename>
3. Install /etc/apt/apt.conf.d/90<packagename> :
DPkg {
Post-Invoke {"test -f /var/run/<packagename> &&
run_locale_server_bootstrap"}
}
4. DPkg Post-Invoke cares for locale servers if necessary
What do you think about this?
Kind regards
Andreas.
--
http://fam-tille.de
