Greg,
As it happens someone else raised the same bug at about the same time.
I happened to come across yours first.
The issue is fairly obvious if one thinks about it and it should not
really have been missed.
On 07/06/12 23:22, Greg Alexander wrote:
Hi -
Thanks for looking into this.
The mysql script caused the creation of a new /run from scratch without
consideration for the old /var/run, which does not honor the contract
specified in:
http://wiki.debian.org/ReleaseGoals/RunDirectory
There it is specified that /var/run is an alias for /run, but the mysql
upgrade process did not cause that result.
Sorry, I'm a little snippy. Upgrade compatibility is a minor obsession
of mine, and the reason that I use Debian (and look down on most other
OSes). I'll delete the sarcastic paragraph and jump straight to the
punchline.
I am running initscripts-2.87dsf-6 (2009 - quite modern, in fact). The
modern mysql packages appear to have an undeclared dependency upon
initscripts-2.88dsf-13.3.
Or in other words, quoting from that ReleaseGoals/RunDirectory document:
Before wheezy, a versioned depends upon initscripts (>= 2.88dsf-13.3)
will be required to ensure the presence of a functional /run.
Since wheezy is not even released yet, and since 17 other packages do
still have declared dependencies on initscripts>= 2.88dsf-13.3, I assume
that is still in effect...
Probably you guys just weren't aware that the /run transition is newer
than any LSB document, so the lsb-base dependency doesn't do anything for
us here.
Cheers,
- Greg
evidence that this is causing a problem. On a standard recent Debian
system /var/run will be a symlink to /run. In fact I could not even see
Debian
On Thu, Jun 07, 2012 at 10:25:10PM +0100, Nicholas Bamber wrote:
severity 676539 minor
tag 676539 +moreinfo
thanks
Greg,
Thanks for pointing out the incompletenesses in our migration. They
will be acted on if substantiated.
I am downgrading the severity because I could not see any actual
evidence that this is causing a problem. On a standard recent Debian
system /var/run will be a symlink to /run. In fact I could not even see
any evidence that this is true. What I think happened is that since
/etc/mysql/debian.cnf already existed, the mysql-server-5.5 postinst
script had no reason to create it afresh.
As for the change it may well (or not) be a pointless change but it is
recommended by section 9.1.4 of the latest version of the Debian policy.
The lintian tool attempts to find and report on violations.
As for libdbd-mysql-perl that is a separate package. If it was an issue
it would require a separate bug report. I had a look through both the
upstream and packaging code and I could not see anywhere where the MySQL
socket file location is defaulted or hardcoded. I think it should be
picked up from the libmysqlclient18 package (which is part the mysql-5.5
package). However libdbd-mysql-perl has not yet been binNMU'ed so that
would be why that is picking up the old location.
If you have any more information please let me know. Otherwise can I
close the ticket?
On 07/06/12 18:10, Greg Alexander wrote:
Package: mysql-server-5.5
Version: 5.5.24+dfsg-2
Severity: important
Dear Maintainer,
Upon upgrading to mysql-server-5.5, I find that /var/run/mysqld has been
needlessly renamed to /run/mysqld.
Pointless renaming is considered harmful!
You forgot to update a few things when you performed this pointless
operation. /etc/mysql/debian.cnf continues to reference /var/run/mysqld.
The perl DBI package continues to reference /var/run/mysqld.
The need to enumerate the innumerable potential dependencies on the
mysqld socket location can be ameliorated through the use of symlinks.
Add this to the postrm file:
ln -s /run/mysqld /var/run/mysqld
But in fact, you could have avoided this whole problem in the first
place by not pointlessly renaming /var/run to /run.
In the future, try not to break things for no reason. We have symlinks
for a reason. Any unix admin who needs /var/run to live in a special
location can achieve this effect using mount or ln already. There is
no need to render every mysql-dependent configuration file suspect to
achieve this end.
If the person who decided to rename /var/run/mysqld to /run/mysqld
should happen to read this thread, I beg you to please consider swearing
off future contribution to open source projects. You are simply not cool
enough for my club.
- Greg
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32.22 (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages mysql-server-5.5 depends on:
ii adduser 3.102
ii debconf [debconf-2.0] 1.5.40
ii libc6 2.13-10
ii libdbi-perl 1.621-1
ii libgcc1 1:4.6.1-4
ii libstdc++6 4.6.1-4
ii lsb-base 3.2-23
ii mysql-client-5.5 5.5.24+dfsg-2
ii mysql-common 5.5.24+dfsg-2
ii mysql-server-core-5.5 5.5.24+dfsg-2
ii passwd 1:4.0.18.1-7
ii perl 5.14.2-11
ii psmisc 20.2-2.1
ii zlib1g 1:1.2.3.4.dfsg-3
Versions of packages mysql-server-5.5 recommends:
ii libhtml-template-perl 2.9-1
ii mailx 1:8.1.2-0.20020411cvs-1
Versions of packages mysql-server-5.5 suggests:
pn tinyca<none>
-- debconf information:
mysql-server/root_password_again: (password omitted)
* mysql-server/root_password: (password omitted)
mysql-server-5.5/postrm_remove_databases: false
mysql-server/error_setting_password:
mysql-server-5.5/nis_warning:
mysql-server-5.5/really_downgrade: false
mysql-server-5.5/start_on_boot: true
mysql-server/password_mismatch:
mysql-server/no_upgrade_when_using_ndb:
_______________________________________________
pkg-mysql-maint mailing list
pkg-mysql-ma...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-mysql-maint
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
