blob: 9e44495ee3b2ae723e58d20f4e95cbe441a47db4 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
|
###########################
## FIXME for 5.1 ##
###########################
* put this trigger-recreation thing into the init scripts -- what?!
###########################################################################
# Here are some information that are only of interest for the current and #
# following Debian maintainers of MySQL. #
###########################################################################
The debian/ directory is under SVN control, see debian/control for URL.
#
# Preparing a new version
#
The new orig.tar.gz (without non-free documentation) is created in /tmp/ when
running this command:
debian/rules get-orig-source
#
# mysqlreport
#
The authors e-mail address is <public@codenode.com>.
#
# Remarks to dependencies
#
libwrap0-dev (>= 7.6-8.3)
According to bug report 114582 where where build problems on
IA-64/sid with at least two prior versions.
psmisc
/usr/bin/killall in the initscript
zlib1g in libmysqlclient-dev:
"mysql_config --libs" ads "-lz"
Build-Dep:
debhelper (>=4.1.16):
See po-debconf(7).
autoconf (>= 2.13-20), automake1.7
Try to get rid of them.
#
# Remarks to the start scripts
#
## initscripts rely on mysqladmin from a different package
We have the problem that "/etc/init.d/mysql stop" relies on mysqladmin which
is in another package (mysql-client) and a passwordless access that's maybe
only available if the user configured his /root/.my.cnf. Can this be a problem?
* normal mode: not because the user is required to have it. Else:
* purge/remove: not, same as normal mode
* upgrade: not, same as normal mode
* first install: not, it depends on mysql-client which at least is unpacked
so mysqladmin is there (to ping). It is not yet configured
passwordles but if there's a server running then there's a
/root/.my.cnf. Anyways, we simply kill anything that's mysqld.
## Passwordless access for the maintainer scripts
Another issue is that the scripts needs passwordless access. To ensure this
a debian-sys-maint user is configured which has process and shutdown privs.
The file with the randomly (that's important!) generated password must be
present as long as the databases remain installed because else a new install
would have no access. This file should be used like:
mysqladmin --defaults-file=/etc/mysql/debian.cnf restart
to avoid providing the password in plaintext on a commandline where it would
be visible to any user via the "ps" command.
## When to start the daemon?
We aim to give the admin full control on when MySQL is running.
Issues to be faced here:
OLD:
1. Debconf asks whether MySQL should be started on boot so update-rc.d is
only run if the answer has been yes. The admin is likely to forget
this decision but update-rc.d checks for an existing line in
/etc/runlevel.conf and leaves it intact.
2. On initial install, if the answer is yes, the daemon has to be started.
3. On upgrades it should only be started if it was already running, everything
else is confusing. Especiall relying on an debconf decision made month ago
is considered suboptimal. See bug #274264
Implementation so far:
prerm (called on upgrade before stopping the server):
check for a running server and set flag if necessary
preinst (called on initial install and before unpacking when upgrading):
check for the debconf variable and set flag if necessary
postinst (called on initial install and after each upgrade after unpacking):
call update-rc.d if debconf says yes
call invoce-rc.d if the flag has been set
Problems remaining:
dpkg-reconfigure and setting mysql start on boot to yes did not start mysql
(ok "start on boot" literally does not mean "start now" so that might have been ok)
NEW:
1. --- no debconf anymore for the sake of simplicity. We have runlevel.conf,
the admin should use it
2. On initial install the server is started.
3. On upgrades the server is started exactly if it was running before so the
runlevel configuration is irrelevant. It will be preserved by the mean of
update-rc.d's builtin check.
Implementation:
prerm (called on upgrade before stopping the server):
check for a running server and set flag if necessary
preinst (called on initial install and before unpacking when upgrading):
check for $1 beeing (initial) "install" and set flag
postinst (called on initial install and after each upgrade after unpacking):
call update-rc.d
call invoce-rc.d if the flag has been set
|
