Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2015-08-08 Thread Andreas Beckmann
On 2015-06-25 11:40, Andreas Beckmann wrote:
 Followup-For: Bug #768815
 
 For wheezy-jessie we ignored the remaining problems in piuparts, but
 for wheezy-jessie-stretch I'd like to get rid of them:
 
 1m41.5s ERROR: FAIL: debsums reports modifications inside the chroot:
   /etc/apache2/conf-available/other-vhosts-access-log.conf
   /etc/apache2/conf-available/localized-error-pages.conf
   /etc/apache2/conf-available/charset.conf
   /etc/apache2/sites-available/default-ssl.conf
   /etc/bash_completion.d/apache2
   /etc/apache2/conf-available/security.conf
   /etc/apache2/sites-available/000-default.conf
 
 With apache2.2-common being gone this should be rather easy.
 IIRC these conffiles were taken over by the apache2 package, so
 all that should be needed are unversioned
  Breaks+Replaces: apache2.2-common
 in the apache2 package.

Or rather make the Conflicts already existing in apache2 unversioned.

 That would ensure the obsolete transitional package is removed
 on upgrades (therefore no more debsums complaining) and maybe also
 forget about the remaining conffile bits in dpkg ...

I tested the above and it ensured the obsolete package gets removed, but
it may need another patch to debsums to not report missing obsolete
conffiles.


Andreas


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c5b11c.4030...@debian.org



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2015-08-08 Thread Andreas Beckmann
On 2015-08-08 22:36, Stefan Fritsch wrote:
 Do you know if there is any practical difference between conflicts and 
 breaks+replaces in this case?

I don't think so. All dependencies on apache-2.2-common should be gone
by now, so removal of that package could happen anytime without
influencing any other package upgrade path.
BTW, Conflicts should come with Replaces, too.

Andreas


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c66a65.5030...@debian.org



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2015-08-08 Thread Stefan Fritsch
On Saturday 08 August 2015 09:34:52, Andreas Beckmann wrote:
  With apache2.2-common being gone this should be rather easy.
  IIRC these conffiles were taken over by the apache2 package, so
  all that should be needed are unversioned
 
   Breaks+Replaces: apache2.2-common
 
  in the apache2 package.
 
 Or rather make the Conflicts already existing in apache2
 unversioned.

Do you know if there is any practical difference between conflicts and 
breaks+replaces in this case?


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4947469.gAttiyAaDV@k



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2015-06-25 Thread Andreas Beckmann
Followup-For: Bug #768815

For wheezy-jessie we ignored the remaining problems in piuparts, but
for wheezy-jessie-stretch I'd like to get rid of them:

1m41.5s ERROR: FAIL: debsums reports modifications inside the chroot:
  /etc/apache2/conf-available/other-vhosts-access-log.conf
  /etc/apache2/conf-available/localized-error-pages.conf
  /etc/apache2/conf-available/charset.conf
  /etc/apache2/sites-available/default-ssl.conf
  /etc/bash_completion.d/apache2
  /etc/apache2/conf-available/security.conf
  /etc/apache2/sites-available/000-default.conf

With apache2.2-common being gone this should be rather easy.
IIRC these conffiles were taken over by the apache2 package, so
all that should be needed are unversioned
 Breaks+Replaces: apache2.2-common
in the apache2 package.

That would ensure the obsolete transitional package is removed
on upgrades (therefore no more debsums complaining) and maybe also
forget about the remaining conffile bits in dpkg ...


Andreas


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150625094007.16742.84135.report...@zam581.zam.kfa-juelich.de



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-20 Thread Stefan Fritsch
On Wednesday 19 November 2014 16:49:44, Andreas Beckmann wrote:
 On 2014-11-18 14:23, Stefan Fritsch wrote:
  I think it would be best to ask the dpkg maintainers if they can
  make dpkg recognize that the obsolete conffiles have been
  removed. If that
 that is a hard part
 
 but I got some weird idea about generalized file ownership:
 
 (the classic ones)
 * you own a file exclusively that you ship (there are special cases
 for m-a same packages)
 * you own a directory shared that you ship
 
 (the weird ones)
 * you own an object exclusively with the property
 ***SHOULD_NOT_EXIST*** i.e. you have a file conflict with any other
 package that wants to own that object, too. so you take-over
 ownership of obsolete conffiles.
 * you own an object exclusively,
 but don't ship it. instead it is generated by maintainer scripts or
 whatever. this is marked with the property either delete-on-remove
 or delete-on-purge - so dpkg could handle proper cleanup on
 removal/purge, too, without the need for maintainer scripts
 performing cleanup. might be handy for
   configuration files, state files, cache files, logfiles, ...
 
 if that does not sound totally insane we should propose this to
 guillem for dpkg 1.20+x

I does sound way too complicated to implement for jessie. I was more 
thinking of one of these:

- whenever dpkg does the check for removal of obsolete conffiles (I 
think it does that just after the postinst of a package runs), do the 
check for all packages that the current package replaces, too.

- simply provide a command line option that we may call in our 
postinst. This would also allow administrators to make dpkg forget 
about conffiles they have deleted by hand.

  is not feasible for Jessie, debsums or piuparts should work around
  this problem so that piuparts tests are still possible. Do you
  agree?
 maybe you have convinced me to fix debsums instead ...
 
 PS: do you need the apache2.2-common transitional package? would
 upgrades work if that would not exist?


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2715975.fdLjBp3eRQ@k



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-19 Thread Andreas Beckmann
On 2014-11-18 14:23, Stefan Fritsch wrote:
 I think it would be best to ask the dpkg maintainers if they can make 
 dpkg recognize that the obsolete conffiles have been removed. If that 

that is a hard part

but I got some weird idea about generalized file ownership:

(the classic ones)
* you own a file exclusively that you ship (there are special cases for
m-a same packages)
* you own a directory shared that you ship

(the weird ones)
* you own an object exclusively with the property ***SHOULD_NOT_EXIST***
  i.e. you have a file conflict with any other package that wants to own
  that object, too. so you take-over ownership of obsolete conffiles.
* you own an object exclusively, but don't ship it. instead it is
generated by maintainer scripts or whatever. this is marked with the
property either delete-on-remove or delete-on-purge - so dpkg could
handle proper cleanup on removal/purge, too, without the need for
maintainer scripts performing cleanup. might be handy for
  configuration files, state files, cache files, logfiles, ...

if that does not sound totally insane we should propose this to guillem
for dpkg 1.20+x

 is not feasible for Jessie, debsums or piuparts should work around 
 this problem so that piuparts tests are still possible. Do you agree?

maybe you have convinced me to fix debsums instead ...

PS: do you need the apache2.2-common transitional package? would
upgrades work if that would not exist?


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546cbc18.60...@debian.org



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-19 Thread Arno Töll
On 19.11.2014 16:49, Andreas Beckmann wrote:
 PS: do you need the apache2.2-common transitional package? would
 upgrades work if that would not exist?

Please see https://lists.debian.org/debian-devel/2014/07/msg00450.html
for all the gory details. We added it very late in the process to work
around people's laziness :/


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature


Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-19 Thread Andreas Beckmann
On 2014-11-19 23:26, Arno Töll wrote:
 On 19.11.2014 16:49, Andreas Beckmann wrote:
 PS: do you need the apache2.2-common transitional package? would
 Please see https://lists.debian.org/debian-devel/2014/07/msg00450.html

Nice writeup. No further questions :-)


Andreas


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546d2fdb.5060...@debian.org



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-18 Thread Stefan Fritsch
Hi Andreas,

On Monday 10 November 2014 00:11:20, Andreas Beckmann wrote:
 On 2014-11-09 19:01, Stefan Fritsch wrote:
  On Sunday 09 November 2014 14:21:34, Andreas Beckmann wrote:
  I'm not sure whether (or how) dpkg-maintscript-helper mv_conffile
  can be used reliably to rename a conffile and switch ownership to
  another package at the same time.
  
  I don't see how there is any way to handle rename and takeofer of
  conffiles at the same time at all. If the rename is done in
  apache2.2- common, how would it know if something went wrong and
  it has to revert the changes?
 
 looks like we have the opportunity to test and implement this right
 now :-)
 
 from the dpkg-maintscript-helper mv_conffile manpage:
 
 Current  implementation:  the preinst checks if the conffile has
 been modified, if yes it's left on place otherwise it's renamed to
 old-conffile.dpkg-remove. On configuration, the postinst removes
 old- conffile.dpkg-remove and renames old-conffile to new-conffile
 if old-conffile is still available. On abort-upgrade/abort-install,
 the postrm renames old-conffile.dpkg-remove  back  to  old-conffile
  if required.
 
 that process would have to be distributed to two packages ...

I am very reluctant to implement something like this now that we are 
in the freeze. The upgrade logic in apache2 is already quite complex 
and has been tested for months. If we split the logic in two package, 
I fear there will be new bugs that will be difficult to find and fix 
until the release.

And in principle I think that apache2 does the right thing. It has 
Replaces: apache2.2-common and should be allowed to take over or 
delete conffiles from apache2.2-common.

I think it would be best to ask the dpkg maintainers if they can make 
dpkg recognize that the obsolete conffiles have been removed. If that 
is not feasible for Jessie, debsums or piuparts should work around 
this problem so that piuparts tests are still possible. Do you agree?

Cheers,
Stefan


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2002865.PAzmxKW3b3@k



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-11 Thread Arno Töll
Hi,

On 10.11.2014 00:11, Andreas Beckmann wrote:
 that process would have to be distributed to two packages ...

We do right that already, the best we can. cf.:

http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/apache2.preinst
http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/apache2.postinst

We can't use dpkg-maintscript helper for the reason you named, as we
renamed the package owning it. However, I believe, we cleanly
remove/take-over the conffiles in the best way dpkg allows us.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature


Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-09 Thread Andreas Beckmann
Package: apache2.2-common
Version: 2.4.10-6
Severity: important

Hi,

this bug blocks doing piuparts wheezy - jessie upgrade tests for the
whole apache2 stack and any rdepends.

debsums: missing file /etc/bash_completion.d/apache2.2-common (from 
apache2.2-common package)
debsums: missing file /etc/apache2/conf.d/charset (from apache2.2-common 
package)
debsums: missing file /etc/apache2/mods-available/authn_alias.load (from 
apache2.2-common package)
debsums: missing file /etc/apache2/mods-available/disk_cache.conf (from 
apache2.2-common package)
debsums: missing file /etc/apache2/conf.d/localized-error-pages (from 
apache2.2-common package)
debsums: missing file /etc/apache2/mods-available/mem_cache.load (from 
apache2.2-common package)
debsums: missing file /etc/apache2/conf.d/other-vhosts-access-log (from 
apache2.2-common package)
debsums: missing file /etc/apache2/mods-available/authn_default.load (from 
apache2.2-common package)
debsums: missing file /etc/apache2/mods-available/authz_default.load (from 
apache2.2-common package)
debsums: missing file /etc/apache2/mods-available/disk_cache.load (from 
apache2.2-common package)
debsums: missing file /etc/apache2/conf.d/security (from apache2.2-common 
package)
debsums: missing file /etc/apache2/sites-available/default-ssl (from 
apache2.2-common package)
debsums: missing file /etc/apache2/mods-available/imagemap.load (from 
apache2.2-common package)
debsums: missing file /etc/apache2/mods-available/cern_meta.load (from 
apache2.2-common package)
debsums: missing file /etc/apache2/mods-available/mem_cache.conf (from 
apache2.2-common package)
debsums: missing file /etc/apache2/sites-available/default (from 
apache2.2-common package)

These are the conffiles that are removed (are there any?) or renamed in
apache2. dpkg does not recognize this and therefore lists the conffiles
as still owned by apache2.2-common.

This seems to be the sequence of actions:

  Preparing to unpack .../apache2.2-common_2.4.10-6_amd64.deb ...
  Unpacking apache2.2-common (2.4.10-6) over (2.2.22-13+deb7u3) ...
  Preparing to unpack .../apache2_2.4.10-6_amd64.deb ...
  Moving obsolete conffile /etc/apache2/mods-available/authz_default.load out 
of the way...

  Unpacking apache2 (2.4.10-6) ...

  Setting up apache2 (2.4.10-6) ...
  Installing new version of config file /etc/logrotate.d/apache2 ...

  Installing new version of config file /etc/init.d/apache2 ...
  Removing obsolete conffile /etc/apache2/mods-available/authz_default.load ...

  Removing obsolete directory /etc/apache2/conf.d
  Enabling module mpm_event.

  Enabling site 000-default.
  Setting up apache2.2-common (2.4.10-6) ...

I think the removal and renaming part needs to be done by apache2.2-common
itself - the files must be moved out of the way in the preinst s.t. dpkg
sees in the unpacking phase that they are gone and no longer remebers 
I own this obsolete conffile. The taken over conffiles need no special
handling here, this is done by apache2 and dpkg will change ownership
as intended.

I'm not sure whether (or how) dpkg-maintscript-helper mv_conffile can
be used reliably to rename a conffile and switch ownership to another
package at the same time. 


Andreas


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20141109132134.16958.33259.report...@zam581.zam.kfa-juelich.de



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-09 Thread Stefan Fritsch
On Sunday 09 November 2014 14:21:34, Andreas Beckmann wrote:
 I'm not sure whether (or how) dpkg-maintscript-helper mv_conffile
 can be used reliably to rename a conffile and switch ownership to
 another package at the same time.

I don't see how there is any way to handle rename and takeofer of 
conffiles at the same time at all. If the rename is done in apache2.2-
common, how would it know if something went wrong and it has to revert 
the changes?

I think dpkg needs to provide an explicit interface for marking 
conffiles as removed. Or piuparts should just ignore missing obsolete 
conffiles.

But I will do an upload that removes the obsolete conffiles. Then 
doing tests with the renamed/taken over conffiles may become easier.


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/3898510.6D6ZZh9HrO@k



Bug#768815: apache2.2-common: debsums reports missing conffiles after wheezy - jessie upgrade

2014-11-09 Thread Andreas Beckmann
On 2014-11-09 19:01, Stefan Fritsch wrote:
 On Sunday 09 November 2014 14:21:34, Andreas Beckmann wrote:
 I'm not sure whether (or how) dpkg-maintscript-helper mv_conffile
 can be used reliably to rename a conffile and switch ownership to
 another package at the same time.
 
 I don't see how there is any way to handle rename and takeofer of 
 conffiles at the same time at all. If the rename is done in apache2.2-
 common, how would it know if something went wrong and it has to revert 
 the changes?

looks like we have the opportunity to test and implement this right now :-)

from the dpkg-maintscript-helper mv_conffile manpage:

Current  implementation:  the preinst checks if the conffile has been
modified, if yes it's left on place otherwise it's renamed to
old-conffile.dpkg-remove. On configuration, the postinst removes old-
conffile.dpkg-remove and renames old-conffile to new-conffile if
old-conffile is still available. On abort-upgrade/abort-install, the
postrm renames old-conffile.dpkg-remove  back  to  old-conffile  if
required.

that process would have to be distributed to two packages ...

but right now I'm not even sure how this case is handled:
* package version 1 has conffile foo with content foo
* user modifies this to set foobar
* package version 2 renames the conffile to bar and changes content to bar
Does dpkg prompt about this modification? Should it?


 I think dpkg needs to provide an explicit interface for marking 
 conffiles as removed. Or piuparts should just ignore missing obsolete 
 conffiles.

piuparts is relying on debsums for this ... debsums has already been
taught not to complain about obsolete conffiles that are no longer owned
by a package

 But I will do an upload that removes the obsolete conffiles. Then 
 doing tests with the renamed/taken over conffiles may become easier.

That's a good idea. Let's see what is remaining afterwards.


Andreas


-- 
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/545ff498.5090...@debian.org