Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

2015-09-08 12:26 GMT+03:00 Andreas Beckmann :
>> Andreas: are you still into making mysql-common a separate source
>> package as you suggested in the summer? I think it would be a good
>> time now.
>
> Ack, I'm in :-)

Great!

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-09-06 22:08, Otto Kekäläinen wrote:
> This is still the status. Over 40 days has already passed of waiting
> for mysql-5.6.

d/copyright needs to be updated, fixed in git.
That is hopefully the only blocker left for a migration.

Btw, why aren't you in Uploaders?

Anything else that should be included in the next upload?
There is a patch for mips64el in #798126
Please get into contact wth the hurd porters to fix #793358

someone should look into handlersocket, there is a new upstream release
that could add mysql 5.6 support.

> Andreas: are you still into making mysql-common a separate source
> package as you suggested in the summer? I think it would be a good
> time now.

Ack, I'm in :-)

IIRC I wrote a lengthy mail with several questions regarding this, but
didn't see a reply so far ...


Andreas

Bug#787533: [debian-mysql] Bug#787533: Bug#787533: Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

2015-08-14 11:18 GMT+03:00 Otto Kekäläinen :
> For the record: mariadb-10.0 with these changes was uploaded to
> unstable weeks ago, but it cannot enter testing, as it now has a
> versioned dependency on mysql-5.6, which due to other problems in that
> package does not enter testing.
>
> For the time beeing, new versions of mariadb-10.0 entering testing is
> tied to mysql-5.6 entering testing, which is a bit suboptimal. For
> example testing still has only 10.0.19 and is missing the security
> fixes included in 10.0.20.

This is still the status. Over 40 days has already passed of waiting
for mysql-5.6.

Andreas: are you still into making mysql-common a separate source
package as you suggested in the summer? I think it would be a good
time now.

Bug#787533: [debian-mysql] Bug#787533: Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

2015-07-19 23:16 GMT+02:00 Otto Kekäläinen o...@seravo.fi:
 I cannot however upload it until a fixed version of mysql-5.6 is
 uploaded and has entered 'testing', as the dependency on mysql-common
 5.6.25 would make all mariadb-10.0 installations in Debian testing to
 fail.

For the record: mariadb-10.0 with these changes was uploaded to
unstable weeks ago, but it cannot enter testing, as it now has a
versioned dependency on mysql-5.6, which due to other problems in that
package does not enter testing.

For the time beeing, new versions of mariadb-10.0 entering testing is
tied to mysql-5.6 entering testing, which is a bit suboptimal. For
example testing still has only 10.0.19 and is missing the security
fixes included in 10.0.20.

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

I gave up on fixing the powerpc build failure for new and will upload
package with all current changes:
https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/log

Great to see that we have so many contributors in this round of packaging! :)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

2015-07-22 22:56 GMT+03:00 Andreas Beckmann a...@debian.org:
 That one was fixed already in December in
 https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/?id=3afe791ed47b897de8fa9be998a4217fc2a36bad

 Robie added recently in 6bc2c1a5 in mysql-5.6 an explicit 'exit 0' at
 the end of the initscript.

 export DEBIAN_SCRIPT_DEBUG=1
 aptitude install mariadb-server-10.0

 I don't want to reply the tests by hand :-)
 I'll just rebuild with exit 0 added and DEBIAN_SCRIPT_DEBUG=1 turned on
 in the script, and thereafter rerun my piuparts torture :-)


Thanks for the extra log you sent in another message. In your piuparts
install the failure line is 204 in the mariadb-server-10.0.postinst
script. I haven't been able to reproduce it on a sid virtual machine,
but I'll keep trying still a few things.

I am however quite sure that you should not add any extra exit 0
anywhere, as this is not an init script problem and the mariadb init
script has been fixed since December anyway.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

Oh darn, error 141 is just another instance of #790875 manifesting.
I had a workaround for stretch and sid and magically that worked for
mysql jessie-sid upgrades, but not for mariadb jessie-sid upgrades.

Looks clean from the piuparts side now (except for libmariadbd-dev
uninstallability).


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-07-22 14:07, Otto Kekäläinen wrote:
 sprint, so the 1.0.20-3 upload will include quite many fixes:
Nice!

This is an excerpt from the logfile of an upgrade jessie - sid+local_packages:
(this should give a good simulation of jessie-stretch upgrades
after the packages have migrated to testing)

[...] 
  Preparing to unpack .../mariadb-client-core-10.0_10.0.20-3_amd64.deb ...
  Unpacking mariadb-client-core-10.0 (10.0.20-3) over (10.0.16-1) ...
  Preparing to unpack .../mariadb-client-10.0_10.0.20-3_amd64.deb ...
  Unpacking mariadb-client-10.0 (10.0.20-3) over (10.0.16-1) ...
  Preparing to unpack .../mariadb-server-core-10.0_10.0.20-3_amd64.deb ...
  Unpacking mariadb-server-core-10.0 (10.0.20-3) over (10.0.16-1) ...
  Setting up mysql-common (5.6.25-3) ...
  Removing obsolete conffile /etc/mysql/conf.d/.keepme ...
  Removing obsolete conffile /etc/mysql/my.cnf ...
  update-alternatives: using /etc/mysql/my.cnf.fallback to provide 
/etc/mysql/my.cnf (my.cnf) in auto mode
  Setting up mariadb-common (10.0.20-3) ...
  update-alternatives: using /etc/mysql/mariadb.cnf to provide 
/etc/mysql/my.cnf (my.cnf) in auto mode
  Preparing to unpack .../mariadb-server-10.0_10.0.20-3_amd64.deb ...
  Stopping MariaDB database server: mysqld.
  Stopping MariaDB database server: mysqld.
  Unpacking mariadb-server-10.0 (10.0.20-3) over (10.0.16-1) ...
[...]
  Preparing to unpack .../mariadb-connect-engine-10.0_10.0.20-3_amd64.deb ...
  Unpacking mariadb-connect-engine-10.0 (10.0.20-3) over (10.0.16-1) ...
[...]
  Setting up mariadb-client-core-10.0 (10.0.20-3) ...
  Setting up mariadb-client-10.0 (10.0.20-3) ...
  Setting up mariadb-server-core-10.0 (10.0.20-3) ...
  Setting up mariadb-server-10.0 (10.0.20-3) ...
  Installing new version of config file /etc/init.d/mysql ...
  Installing new version of config file /etc/logrotate.d/mysql-server ...
  Stopping MariaDB database server: mysqld.
  dpkg: error processing package mariadb-server-10.0 (--configure):
   subprocess installed post-installation script returned error exit status 141
  Setting up gcc-4.8-base:amd64 (4.8.5-1) ...
  Setting up gcc-4.9-base:amd64 (4.9.3-2) ...
  dpkg: dependency problems prevent configuration of 
mariadb-connect-engine-10.0:
   mariadb-connect-engine-10.0 depends on mariadb-server-10.0 | 
mariadb-galera-server-10.0; however:
Package mariadb-server-10.0 is not configured yet.
Package mariadb-galera-server-10.0 is not installed.
  
  dpkg: error processing package mariadb-connect-engine-10.0 (--configure):
   dependency problems - leaving unconfigured
  Processing triggers for libc-bin (2.19-19) ...
  Processing triggers for systemd (222-2) ...
  Errors were encountered while processing:
   mariadb-server-10.0


What's the meaning of exit status 141?
This seems to happen on all jessie-sid upgrade paths involving 
mariadb-server-10.0
The packages were built from my branch, so don't include your recent commits.

I did not encounter this for upgrades from stretch.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-07-22 19:18, Andreas Beckmann wrote:
 What's the meaning of exit status 141?
 This seems to happen on all jessie-sid upgrade paths involving 
 mariadb-server-10.0
 The packages were built from my branch, so don't include your recent commits.

Hmm, this could be the mariadb variant of mysql bug #790249, and adding
'exit 0' at the end of the initscript could be sufficient to fix this.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-07-22 21:45, Otto Kekäläinen wrote:
 Hmm, this could be the mariadb variant of mysql bug #790249, and adding
 'exit 0' at the end of the initscript could be sufficient to fix this.
 
 That one was fixed already in December in
 https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/?id=3afe791ed47b897de8fa9be998a4217fc2a36bad

Robie added recently in 6bc2c1a5 in mysql-5.6 an explicit 'exit 0' at
the end of the initscript.

 export DEBIAN_SCRIPT_DEBUG=1
 aptitude install mariadb-server-10.0

I don't want to reply the tests by hand :-)
I'll just rebuild with exit 0 added and DEBIAN_SCRIPT_DEBUG=1 turned on
in the script, and thereafter rerun my piuparts torture :-)


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

2015-07-22 20:34 GMT+03:00 Andreas Beckmann a...@debian.org:
 On 2015-07-22 19:18, Andreas Beckmann wrote:
 What's the meaning of exit status 141?
 This seems to happen on all jessie-sid upgrade paths involving 
 mariadb-server-10.0
 The packages were built from my branch, so don't include your recent commits.

 Hmm, this could be the mariadb variant of mysql bug #790249, and adding
 'exit 0' at the end of the initscript could be sufficient to fix this.

That one was fixed already in December in
https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/?id=3afe791ed47b897de8fa9be998a4217fc2a36bad

I don't know what is status 141.

To get more info please try:

export DEBIAN_SCRIPT_DEBUG=1
aptitude install mariadb-server-10.0

This can be seen actually already in
https://piuparts.debian.org/testing2sid/fail/mariadb-server-10.0_10.0.20-2.log
so I the issue is older than your changes. Funny that
https://tracker.debian.org/pkg/mariadb-10.0 did not steer attenttion
to this testing2sid issue, only sid issue (which is different).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-07-19 23:16, Otto Kekäläinen wrote:
 I have pulled this branch and it is now part of
 https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/log/?id=refs/heads/master

Thanks!

 I cannot however upload it until a fixed version of mysql-5.6 is
 uploaded 

that will probably happen today

 and has entered 'testing', as the dependency on mysql-common
 5.6.25 would make all mariadb-10.0 installations in Debian testing to
 fail.

That won't work, mysql-5.6 and mariadb-10.0 will have to enter testing
together or mariadb-10.0 needs to be removed first (since mysql-common
Breaks unfixed mariadb-common).


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

2015-07-22 13:53 GMT+03:00 Andreas Beckmann a...@debian.org:
 and has entered 'testing', as the dependency on mysql-common
 5.6.25 would make all mariadb-10.0 installations in Debian testing to
 fail.

 That won't work, mysql-5.6 and mariadb-10.0 will have to enter testing
 together or mariadb-10.0 needs to be removed first (since mysql-common
 Breaks unfixed mariadb-common).

Ok, I'll prepare the upload of new mariadb-10.0 today then.

I've been lucky to get lot's of contributions lately and also I did
quite a lot of work myself yesterday/today as I met Sergei G for a
sprint, so the 1.0.20-3 upload will include quite many fixes:
https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/log

This morning I got access to a powerpc builder machine and I hope to
fix https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=792780 too
quickly before the upload.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: [debian-mysql] Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

2015-07-17 13:55 GMT+03:00 Andreas Beckmann a...@debian.org:
 git://git.debian.org/users/anbe/tmp/mariadb-10.0.git

 Andreas Beckmann (4):
   mariadb-common: make mysql-common dependency versioned
   mariadb-common.postinst: drop fallback my.cnf symlink management
   simplify mariadb-common maintainer scripts
   mariadb-common.preinst: undo my.cnf symlink and my.cnf.old from the 
 fallback

I have pulled this branch and it is now part of
https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/log/?id=refs/heads/master

I cannot however upload it until a fixed version of mysql-5.6 is
uploaded and has entered 'testing', as the dependency on mysql-common
5.6.25 would make all mariadb-10.0 installations in Debian testing to
fail.

Thank you Andreas for taking the time to review both mysql-5.6
packaging and mariadb-10.0 packaging (which is based on mysql-5.6
packaging from over a year ago).


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

Followup-For: Bug #787533
Control: tag -1 patch

Hi Otto,

you can find the patches needed to fix this issue in

git://git.debian.org/users/anbe/tmp/mariadb-10.0.git

Andreas Beckmann (4):
  mariadb-common: make mysql-common dependency versioned
  mariadb-common.postinst: drop fallback my.cnf symlink management
  simplify mariadb-common maintainer scripts
  mariadb-common.preinst: undo my.cnf symlink and my.cnf.old from the 
fallback

See #792080 for details and corresponding patches for mysql-common.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: [debian-mysql] Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

Hello!

mysql-5.6 is now in unstable, but it has many problems and does not
seem to arrive in testing any soon..?
https://tracker.debian.org/pkg/mysql-5.6

When mysql-5.6 is in testing it should be safe for me to remove the
temporary mv line from mariadb-10.0 in favour of only using the
mysql-common provided new update-alternatives script.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: [debian-mysql] Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-06-15 11:09, Robie Basak wrote:
 The new mysql-common replaces the /etc/mysql/my.cnf conffile with a
 non-conffile maintainer-script-manager symlink (via
 update-alternatives). It is in VCS, though I want to fix a separate bug
 before I upload to minimise the impact on users of unstable and testing
 who will transition from 5.5 to 5.6 as soon as I upload.

as I promised here is a review:

a few comments from just looking at the commit 61e2b53

* mysql-common.postinst:
  - why is the fallback alternative being installed before #DEBHELPER#?
won't that confuse dpkg-maintscript-helper?
at least comment on it, the explanation below is very nice

* mysql-common.postrm:
  - upon purge, delete /etc/mysql/my.cnf.migrated
  - do not use update-alternatives --remove-all, remove only the 
alternatives (possibly) installed by this package (ordered lowest 
to highest priority)
update-alternatives --remove is a silent no-op if the alternative 
does not exist
  - rmdir /etc/mysql should be the last step for purge, not the first


How does the migration work if the mariadb-common mishandling of my.cnf has 
been performed?

from mariadb-common.postinst:

  configure)
# New packaging paradigm for my.cnf as of Dec-2014 for sharing mysql
# variants in Ubuntu. If the new mysql-common package does not provide
# the update-alternatives facility, fall back to creating a symlink
if [ -f /usr/share/mysql-common/configure-symlinks ]
then
  /usr/share/mysql-common/configure-symlinks install mariadb 
/etc/mysql/mariadb.cnf
else
  # As configure can be called many times, don't re-create the symlink
  # if it is there already
  if [ ! -L /etc/mysql/my.cnf ]
  then
echo Notice: configure-symlinks trigger could not be called.
echo Creating /etc/mysql/my.cnf as a symlink that points to 
mariadb.cnf.
mv -f /etc/mysql/my.cnf /etc/mysql/my.cnf.old
ln -sf mariadb.cnf /etc/mysql/my.cnf
  fi
fi
  ;;


how does dpkg-maintscript-helper rm_conffile cope with the conffile being 
replaced with a symlink to a different file?
I expect you want to use my.cnf.old as my.cnf.migrated if and only if it was 
modified
and you never want to use (a symlink to) mariadb.cnf as my.cnf.migrated

mysql-common needs to Breaks: mariadb-common ( 
version-where-that-mess-was-removed-again~)
and mysql-common.preinst may have to undo this before #DEBHELPER#
(mariadb-common may have been removed but not purged before the new 
mysql-common gets installed)
(or it may have been purged as well ... probably leaving my.cnf.old

(note: the mariadb.cnf alternative for my.cnf will be reinstalled correctly 
once the fixed mariadb-common gets configured (and that happens after 
mysql-common got configured)


it should be easy to detect: 

  if [ -L /etc/mysql/my.cnf ]  [ $(readlink /etc/mysql/my.cnf) = 
mariadb.cnf ] ; then ...


The important part is that dpkg cleanly forgets everything about the old 
conffile my.cnf,
otherwise tools like debsums will spew errors since the remembered md5sum does 
not match


Andreas

PS: so far I didn't test anything, just looked at commits (and 
mariadb-common.postinst)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: [debian-mysql] Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-06-15 11:09, Robie Basak wrote:
 On Sun, Jun 14, 2015 at 02:47:00AM +0300, Otto Kekäläinen wrote:
 ..so at the moment the only thing I can do is to revert all mysql-5.6
 compatibility in MariaDB, which would be a huge waste of everybody's
 time. Can't we make an exception from the policy here as clearly the
 point of the policy is to make the packages as clean as possible, not
 impossible?
 
 I'm sorry, I had failed to realise that mariadb was affected by my delay
 in uploading mysql-5.6 in this way. I am working on an upload of
 mysql-5.6 to fix mysql-common.

Good news!

 The new mysql-common replaces the /etc/mysql/my.cnf conffile with a
 non-conffile maintainer-script-manager symlink (via
 update-alternatives). It is in VCS, though I want to fix a separate bug
 before I upload to minimise the impact on users of unstable and testing
 who will transition from 5.5 to 5.6 as soon as I upload.

I'll take a look at this :-)

 Maybe this bug can be reassigned to mysql-common,
No, the fixup code in mariadb has to go away.

 or its severity in
 mariadb reduced? It doesn't make sense to remove mariadb from testing.
ACK.

Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: [debian-mysql] Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Robie Basak]

On Sun, Jun 14, 2015 at 02:47:00AM +0300, Otto Kekäläinen wrote:
 ..so at the moment the only thing I can do is to revert all mysql-5.6
 compatibility in MariaDB, which would be a huge waste of everybody's
 time. Can't we make an exception from the policy here as clearly the
 point of the policy is to make the packages as clean as possible, not
 impossible?

I'm sorry, I had failed to realise that mariadb was affected by my delay
in uploading mysql-5.6 in this way. I am working on an upload of
mysql-5.6 to fix mysql-common.

The new mysql-common replaces the /etc/mysql/my.cnf conffile with a
non-conffile maintainer-script-manager symlink (via
update-alternatives). It is in VCS, though I want to fix a separate bug
before I upload to minimise the impact on users of unstable and testing
who will transition from 5.5 to 5.6 as soon as I upload.

Maybe this bug can be reassigned to mysql-common, or its severity in
mariadb reduced? It doesn't make sense to remove mariadb from testing.

Robie


signature.asc
Description: Digital signature

Bug#787533: [debian-mysql] Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

2015-06-11 21:56 GMT+03:00 Andreas Beckmann a...@debian.org:
 This my.cnf modification was introduced in commit
 https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/?id=90b6bde63c8128eb7f54f16dfeec88081e4bdb0d

 That is, sorry, so utterly wrong ...
 Renaming the old my.cnf must be done by mysql-common (using
 dpkg-maintscript-helper mv_conffile), because that is the only way to
 make dpkg forget about the old conffile (and its hashes) that will be
 replaced by a symlink which is (probably) managed by scripts and not by
 dpkg.

 It as absolutely necessary to do, otherwise the package is broken.

 Depends: mysql-common (= FIXED_VERSION)

 And yes, this config file transition should have started in
 mysql-common, not mariadb.

Yes, but I don't have access to upload mysql-common, I can only
maintain the mariadb-10.0 package. If I add to mariadb-10.0 Depends:
mysql-common (= 5.6) it will stop working for all users in
unstable/testing.

..so at the moment the only thing I can do is to revert all mysql-5.6
compatibility in MariaDB, which would be a huge waste of everybody's
time. Can't we make an exception from the policy here as clearly the
point of the policy is to make the packages as clean as possible, not
impossible?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: [debian-mysql] Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

On 2015-06-08 13:52, Otto Kekäläinen wrote:
 Hello!
 
 2015-06-02 18:07 GMT+03:00 Andreas Beckmann a...@debian.org:
 ..
 during a test with piuparts I noticed your package modifies conffiles.
 This is forbidden by the policy, see
 https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files
 
 This my.cnf modification was introduced in commit
 https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/?id=90b6bde63c8128eb7f54f16dfeec88081e4bdb0d

That is, sorry, so utterly wrong ...
Renaming the old my.cnf must be done by mysql-common (using
dpkg-maintscript-helper mv_conffile), because that is the only way to
make dpkg forget about the old conffile (and its hashes) that will be
replaced by a symlink which is (probably) managed by scripts and not by
dpkg.

 It as absolutely necessary to do, otherwise the package is broken.

Depends: mysql-common (= FIXED_VERSION)

And yes, this config file transition should have started in
mysql-common, not mariadb.


Andreas


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: [debian-mysql] Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Otto Kekäläinen]

Hello!

2015-06-02 18:07 GMT+03:00 Andreas Beckmann a...@debian.org:
..
 during a test with piuparts I noticed your package modifies conffiles.
 This is forbidden by the policy, see
 https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files

This my.cnf modification was introduced in commit
https://anonscm.debian.org/cgit/pkg-mysql/mariadb-10.0.git/commit/?id=90b6bde63c8128eb7f54f16dfeec88081e4bdb0d

It as absolutely necessary to do, otherwise the package is broken.

The engineering behind this is a transition in progress to adapt to
new MySQL 5.6 packaging, which unfortunately isn't uploaded yet. It
has been over 6 months since I did the changes requested by people who
where in progress of creating the MySQL 5.6 packages, yet they've
failed to complete the same changes themself as they requested I
should do.

If the MySQL packages are not maintained in a few months, then we
should maybe consider MySQL 5.6 in Debian abandoned since it hasn't
got any uploads in almost a year
(https://tracker.debian.org/pkg/mysql-5.6) and I could revert all
MySQL 5.6 adaptations in the MariaDB packages.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#787533: mariadb-common: modifies conffiles (policy 10.7.3): /etc/mysql/my.cnf

[Andreas Beckmann]

Package: mariadb-common
Version: 10.0.19-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package modifies conffiles.
This is forbidden by the policy, see
https://www.debian.org/doc/debian-policy/ch-files.html#s-config-files

10.7.3: [...] The easy way to achieve this behavior is to make the
configuration file a conffile. [...] This implies that the default
version will be part of the package distribution, and must not be
modified by the maintainer scripts during installation (or at any
other time).

Note that once a package ships a modified version of that conffile,
dpkg will prompt the user for an action how to handle the upgrade of
this modified conffile (that was not modified by the user).

Further in 10.7.3: [...] must not ask unnecessary questions
(particularly during upgrades) [...]

If a configuration file is customized by a maintainer script after
having asked some debconf questions, it may not be marked as a
conffile. Instead a template could be installed in /usr/share and used
by the postinst script to fill in the custom values and create (or
update) the configuration file (preserving any user modifications!).
This file must be removed during postrm purge.
ucf(1) may help with these tasks.
See also https://wiki.debian.org/DpkgConffileHandling

In https://lists.debian.org/debian-devel/2012/09/msg00412.html and
followups it has been agreed that these bugs are to be filed with
severity serious.

debsums reports modification of the following files,
from the attached log (scroll to the bottom...):

  /etc/mysql/my.cnf


cheers,

Andreas


mariadb-common_10.0.19-1.log.gz
Description: application/gzip