Re: Solutions for the Apache upgrade hell
At Wed, 23 Jul 2014 01:52:30 +0200,
Arno Töll wrote:
However, if you call aptitude --purge-unused:
- apt purges apache2.2-common. This calls apache2.2-common's postrm
purge, wiping all our configuration
- install apache2{-bin,-data}
- preinst apache2 detects an upgrade, but has no clue about the previous
state, because apt purged everything before we could look at it
- force removal of old modules as there is no apache2.2-common anymore
- postinst apache2 is a bit helpless and works through, but does not
treat the installation as new and does therefore not set system defaults
as it thinks we're upgrading
What about doing a stable update to apache2.2-common adding a
confirmation prompt to one of the maintainer scripts similar to the
confirmation prompt you get when you remove the kernel you are
currently running? Such a small change should be okay for stable.
We probably don't want to add a confirmation for every purge, but I
also don't know of an easy way to figure out that the package is (1)
purged and not only removed and (2) that is done because of the
upgrade. When postrm is called with purge the configuration files
are already removed, so that does't really help. Doing ps auxww |
grep purge is a bit hackish, but maybe it is good enough for what we
want to do.
With regards to detecting the upgrade, the first thing apt does is
purging apache2.2-common, so none of the other apache packages are
installed when that happens. Maybe it is good enough to check whether
the apache2-data packages is available? Detecting that the purge
happens after the upgrade can probably be done by checking which
package owns the configuration files.
Kind regards,
Jeroen Dekkers
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k374nurl.wl%jer...@dekkers.ch
Re: Solutions for the Apache upgrade hell
On 21.07.2014 20:58, Vincent Lefevre wrote: Yes, and a consequence of this loss is that dpkg fails. dpkg does not at all fail. If anything dpkg errors out because Apache's maintainer script failed, because invoke.rc-d apache2 restart failed, because ... you guess it, somebody removed the .load symlinks we expect to be there. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Solutions for the Apache upgrade hell
On 2014-07-22 22:10:07 +0200, Arno Töll wrote: On 21.07.2014 20:58, Vincent Lefevre wrote: Yes, and a consequence of this loss is that dpkg fails. dpkg does not at all fail. If anything dpkg errors out because Apache's maintainer script failed, because invoke.rc-d apache2 restart failed, because ... you guess it, somebody removed the .load symlinks we expect to be there. I didn't say that this was dpkg's fault. Then, errors out and fails are synonymous here. The error is fatal and the system is left in an inconsistent state. The user must fix things manually then run apt-get install -f, hoping things are really fixed... BTW, I'm wondering whether the fact that invoke.rc-d apache2 restart fails should make the postinst script fail and affect the whole upgrade. If the goal is to make the user notice that Apache doesn't run, this is rather unnecessary: In any case, the user should test his web server after an Apache upgrade (or other major upgrade in the system), even when everything seems fine during the upgrade. This should be regarded more as a run-time failure than an install-time failure. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140722231930.ga3...@xvii.vinc17.org
Re: Solutions for the Apache upgrade hell
* Arno Töll a...@debian.org [140722 22:10]: On 21.07.2014 20:58, Vincent Lefevre wrote: Yes, and a consequence of this loss is that dpkg fails. dpkg does not at all fail. If anything dpkg errors out because Apache's maintainer script failed, because invoke.rc-d apache2 restart failed, because ... you guess it, somebody removed the .load symlinks we expect to be there. As a mere bystander I still don't really understand the underlying issue. You're basically saying that /some/ conffiles are kept, and others are purged and reinstalled? Possible radical solution: abandon old apache binary package names [of those that ship conffiles], introduce a new set of names, Conflict/Break (but not Replace?) the old ones and have all modules depend on the new packages. 3rdparty module packages will then prevent upgrades or get deinstalled, and users get a fresh config that works, but may not do anything useful. C. -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140722231901.gb96...@sx.home.zeha.at
Re: Solutions for the Apache upgrade hell
On 2014-07-23 01:19:01 +0200, Christian Hofstaedtler wrote: * Arno Töll a...@debian.org [140722 22:10]: On 21.07.2014 20:58, Vincent Lefevre wrote: Yes, and a consequence of this loss is that dpkg fails. dpkg does not at all fail. If anything dpkg errors out because Apache's maintainer script failed, because invoke.rc-d apache2 restart failed, because ... you guess it, somebody removed the .load symlinks we expect to be there. As a mere bystander I still don't really understand the underlying issue. You're basically saying that /some/ conffiles are kept, and others are purged and reinstalled? The issue is that they are purged, but *not* reinstalled. Possible radical solution: abandon old apache binary package names [of those that ship conffiles], introduce a new set of names, Conflict/Break (but not Replace?) the old ones and have all modules depend on the new packages. 3rdparty module packages will then prevent upgrades or get deinstalled, and users get a fresh config that works, but may not do anything useful. The issue is not with 3rd-party module packages (specifically), but with the standard modules. And without these standard modules, Apache cannot be started. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140722232912.gc3...@xvii.vinc17.org
Re: Solutions for the Apache upgrade hell
On 23.07.2014 01:19, Christian Hofstaedtler wrote:
Possible radical solution: abandon old apache binary package names
[of those that ship conffiles], introduce a new set of names,
Conflict/Break (but not Replace?) the old ones and have all modules
depend on the new packages.
3rdparty module packages will then prevent upgrades or get
deinstalled, and users get a fresh config that works, but may not do
anything useful.
That's exactly what we do. The Apache2 (Wheezy) packaging is a bit
simplified:
- apache2: empty meta package
- apache2.2-common: conffiles, MPM management, executables, init
scripts, maintainer scripts
- apache2.2-bin: modules and executables outside $PATH
Third party packages depend on apache2.2-common as they interact with
a2enmod, .load files etc.
Apache 2.4 packaging (Jessie) is
- apache2: maintainer scripts, conffiles
- apache2-bin: binaries, modules
- apache2-data shared arch:all data
In Wheezy, modules depend on apache2.2-common for historical reasons (I
guess, this predates my involvement into the package). For the upgrade
we need to get rid of those modules, as their ABI is not compatible to
Apache 2.4. At runtime this will fail to run, with Apache erroring out
because of incompatible shared module libraries being loaded into the
binary.
Therefore, we must get rid of the apache2.2-common package so that dpkg
forces removal of those module depending on that. If we Provide:
apache2.2-common in apache2, dpkg would consider the dependency
satisfied and we run into the same problem again. Likewise, if we add a
transitional package depending on apache2 [1].
Now, the usual upgrade process is this (consider related transitional
packages are in place to make this happen):
- install apache2{-bin,-data}
- preinst apache2 checks the apache2.2-common conffiles and transitions
them to apache2 by taking them over
- force removal of old modules as there is no apache2.2-common anymore
- postinst apache2 refreshes our stuff, does lots of upgrade handling etc
However, if you call aptitude --purge-unused:
- apt purges apache2.2-common. This calls apache2.2-common's postrm
purge, wiping all our configuration
- install apache2{-bin,-data}
- preinst apache2 detects an upgrade, but has no clue about the previous
state, because apt purged everything before we could look at it
- force removal of old modules as there is no apache2.2-common anymore
- postinst apache2 is a bit helpless and works through, but does not
treat the installation as new and does therefore not set system defaults
as it thinks we're upgrading
As soon as we add in addition to all this cruft an apache2.2-common
transitional package, apt does not purge the package anymore, and we can
properly upgrade. However, this comes at the side effect, that all old
and ABI breaking modules aren't forcibly removed causing havoc at
runtime later unless we add lots of versioned breaks [2].
[1] which is in NEW as of today by the way
[2]
http://anonscm.debian.org/cgit/pkg-apache/apache2.git/tree/debian/control?id=596d18e0bc7e23b2a897f4e1bfb4f1864c8d373e#n127
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
signature.asc
Description: OpenPGP digital signature
Re: Solutions for the Apache upgrade hell
On 23.07.2014 01:19, Vincent Lefevre wrote: BTW, I'm wondering whether the fact that invoke.rc-d apache2 restart fails should make the postinst script fail and affect the whole upgrade. It does actually as we fixed #716921 a while back. If the goal is to make the user notice that Apache doesn't run, this is rather unnecessary: In any case, the user should test his web server after an Apache upgrade (or other major upgrade in the system), even when everything seems fine during the upgrade. This should be regarded more as a run-time failure than an install-time failure. ... which we do. Yet people, including you, blame us for that data loss as you start the (re-)server at runtime afterwards even though the installation completes. :-) -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Solutions for the Apache upgrade hell
On 2014-07-23 02:05:26 +0200, Arno Töll wrote: On 23.07.2014 01:19, Vincent Lefevre wrote: BTW, I'm wondering whether the fact that invoke.rc-d apache2 restart fails should make the postinst script fail and affect the whole upgrade. It does actually as we fixed #716921 a while back. OK, I forgot that (I solved the problem before this was fixed IIRC). If the goal is to make the user notice that Apache doesn't run, this is rather unnecessary: In any case, the user should test his web server after an Apache upgrade (or other major upgrade in the system), even when everything seems fine during the upgrade. This should be regarded more as a run-time failure than an install-time failure. ... which we do. Yet people, including you, blame us for that data loss as you start the (re-)server at runtime afterwards even though the installation completes. :-) Well, with the fix above, this is now a separate problem. Unfortunately it seems that there are no really good solutions. One can at least suppose that the user keeps backups, at least before such a major upgrade. Now, thinking again about your first mail: * Ignore the problem, and refer to the manpage of aptitude without proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING. The bad news is, we can't tell this before it's too late, such as in a NEWS file - and we know, everybody reads release notes too, right? I don't understand that: Why is it too late? The NEWS.Debian file is displayed by apt-listchanges *before* the user accepts the upgrade. So, the user should be aware of the problem. If the user doesn't read the NEWS.Debian file (which is there to present important differences, regressions..., i.e. something that the user must really know in general), then this is his fault. Note: the NEWS.Debian part for apache2 2.4.1-1 is rather lengthy (which is normal here). So, information related to data loss must be put first, with a big WARNING, so that the user doesn't miss it. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140723013341.ge3...@xvii.vinc17.org
Re: Solutions for the Apache upgrade hell
On 2014-07-17 15:44:18 +0200, Arno Töll wrote: On 17.07.2014 15:38, Christian Hofstaedtler wrote: My understanding was that the new apache binaries would install new config files, and it would then work? (With the correct replaces/breaks/...) Yes. However, Apache has a notable number of configuration files (not conffiles), namely symlinks from, e.g. mods-enabled to mods-available, resulting in the working configuration users would like to have. These are being lost if and only if people use --purge during an upgrade as for today, and perhaps for the release unless I use either alternative highlighted initially. Yes, and a consequence of this loss is that dpkg fails. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140721185838.ga18...@xvii.vinc17.org
Re: Solutions for the Apache upgrade hell
* Vincent Lefevre vinc...@vinc17.net [140717 04:02]: On 2014-07-17 03:21:28 +0200, Christian Hofstaedtler wrote: * Arno Töll a...@debian.org [140713 13:25]: * Ignore the problem, and refer to the manpage of aptitude without proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING. The bad news is, we can't tell this before it's too late, such as in a NEWS file - and we know, everybody reads release notes too, right? I'm expressing support for this, and/or your second option. Any non-trivial setup will need config changes anyway, and any sane person already uses version control for /etc + config management for such setups. Actually the problem is not the data loss. The problem is the upgrade failure. My understanding was that the new apache binaries would install new config files, and it would then work? (With the correct replaces/breaks/...) -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717133835.ga47...@sx.intern.ewave.at
Re: Solutions for the Apache upgrade hell
On 17.07.2014 15:38, Christian Hofstaedtler wrote: My understanding was that the new apache binaries would install new config files, and it would then work? (With the correct replaces/breaks/...) Yes. However, Apache has a notable number of configuration files (not conffiles), namely symlinks from, e.g. mods-enabled to mods-available, resulting in the working configuration users would like to have. These are being lost if and only if people use --purge during an upgrade as for today, and perhaps for the release unless I use either alternative highlighted initially. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Solutions for the Apache upgrade hell
On Jo, 17 iul 14, 03:17:35, Vincent Lefevre wrote: On 2014-07-16 14:28:00 +0200, David Kalnischkies wrote: On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote: I do that too. I haven't seen any official documentation saying that this is a bad thing to do. aptitude actively warns against it as highlighted in this thread. Wrong! I purge removed packages almost all the time with aptitude, and I've never seen any warning! From aptitude(8) --purge-unused If Aptitude::Delete-Unused is set to “true” (its default), then in addition to removing each package that is no longer required a by any installed package, aptitude will also purge them, removing their configuration files and perhaps other important data. For more information about which packages are considered to be “unused”, see the section “Managing Automatically Installed Packages” in the aptitude reference manual. THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING! This corresponds to the configuration option Aptitude::Purge-Unused. Yes, this is probably not what you understood as actively, but this thread is also not about running 'aptitude purge', but 'full-upgrade', and if you change the default... Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Unsafe --purge-unused at dist-upgrade (Was: Solutions for the Apache upgrade hell)
Could we please decouple the --purge-unused thread with the Solutions for the Apache upgrade hell thread? It's getting confusing and I am only interested about Apache2 and not about aptitude. Thanks, O. On Thu, Jul 17, 2014, at 23:32, Andrei POPESCU wrote: On Jo, 17 iul 14, 03:17:35, Vincent Lefevre wrote: On 2014-07-16 14:28:00 +0200, David Kalnischkies wrote: On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote: I do that too. I haven't seen any official documentation saying that this is a bad thing to do. aptitude actively warns against it as highlighted in this thread. Wrong! I purge removed packages almost all the time with aptitude, and I've never seen any warning! From aptitude(8) --purge-unused If Aptitude::Delete-Unused is set to “true” (its default), then in addition to removing each package that is no longer required a by any installed package, aptitude will also purge them, removing their configuration files and perhaps other important data. For more information about which packages are considered to be “unused”, see the section “Managing Automatically Installed Packages” in the aptitude reference manual. THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING! This corresponds to the configuration option Aptitude::Purge-Unused. Yes, this is probably not what you understood as actively, but this thread is also not about running 'aptitude purge', but 'full-upgrade', and if you change the default... -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405634901.20492.142887693.68bb6...@webmail.messagingengine.com
Re: Solutions for the Apache upgrade hell
Hi, On 14.07.2014 14:05, Josselin Mouette wrote: How about creating a new apache2-config package just to move these configuration files? for the record: from an informal request the Release Team does not seem to be comfortable with anything like that. Therefore, I suspect if anything, I need to implement a solution which does not involve any packaging changes to packages released with Wheezy. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Solutions for the Apache upgrade hell
On 2014-07-13 13:17:24 +0200, Arno Töll wrote: Unfortunately it turns out, that /a lot/ of people use aptitude --purge-unused safe-upgrade, or the apt equivalent apt-get dist-upgrade --purge which causes dpkg to purge the user's configuration, in particular enabled modules, during the upgrade because apache2.2-common disappears in that step. [...] Is there any reason why apt-get/aptitude removes the config files just after the package is removed, and not at the end of the upgrade process? IMHO, doing the later is safer and would solve this problem with Apache. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140716094125.gb6...@xvii.vinc17.org
Re: Solutions for the Apache upgrade hell
On 2014-07-14 08:53:22 +, Thorsten Glaser wrote: But I normally use apt-get --purge dist-upgrade both to upgrade across distros and to stay within one distro (or sid), because otherwise I get issues: * Running upgrade before dist-upgrade sometimes doesn't get the dependencies right * Running dist-upgrade without --purge will keep packages in 'rc' state around, which a later APT call will not even recognise; you need to manually dpkg --purge pkg1 pkg2 ... to get rid of them I do that too. I haven't seen any official documentation saying that this is a bad thing to do. Purging packages in 'rc' state later is not really an option, as I sometimes want to keep the config files of some particular packages that have been removed... unless APT can differentiate packages that have manually been removed and those that have automatically been removed during a dist-upgrade. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140716093631.ga6...@xvii.vinc17.org
Re: Solutions for the Apache upgrade hell
Hi! On Wed, 2014-07-16 at 11:41:25 +0200, Vincent Lefevre wrote: On 2014-07-13 13:17:24 +0200, Arno Töll wrote: Unfortunately it turns out, that /a lot/ of people use aptitude --purge-unused safe-upgrade, or the apt equivalent apt-get dist-upgrade --purge which causes dpkg to purge the user's configuration, in particular enabled modules, during the upgrade because apache2.2-common disappears in that step. [...] Is there any reason why apt-get/aptitude removes the config files just after the package is removed, and not at the end of the upgrade process? IMHO, doing the later is safer and would solve this problem with Apache. It just calls dpkg with --purge. Something that would also fix this issue (among other upgrade problems) is using dpkg “transactions”: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579790#82 Thanks, Guillem -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140716114612.ga3...@gaara.hadrons.org
Re: Solutions for the Apache upgrade hell
On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote: On 2014-07-14 08:53:22 +, Thorsten Glaser wrote: But I normally use apt-get --purge dist-upgrade both to upgrade across distros and to stay within one distro (or sid), because otherwise I get issues: * Running upgrade before dist-upgrade sometimes doesn't get the dependencies right Revolutionary idea: Report a bug, so that it can be worked out as this is how thousands of users who are capable of reading release notes will upgrade and you don't want them to run into the same problems you ran into, do you? Bonuspoints if you can fix it on way or the other, too. * Running dist-upgrade without --purge will keep packages in 'rc' state around, which a later APT call will not even recognise; you need to manually dpkg --purge pkg1 pkg2 ... to get rid of them Looks like your upgrade process isn't working as you expect, as you are still stuck with oldoldstable… I do that too. I haven't seen any official documentation saying that this is a bad thing to do. aptitude actively warns against it as highlighted in this thread. Official documentation also doesn't say that running 'rm -rf --no-preserve-root /' is a bad thing, but you seem to not run it anyway. In fact, official documentation says exactly how you should perform an upgrade, so it says you at least what is a good thing and you can predict from that that other ways may be less good. Purging packages in 'rc' state later is not really an option, as I sometimes want to keep the config files of some particular packages that have been removed... unless APT can differentiate packages that have manually been removed and those that have automatically been removed during a dist-upgrade. I don't understand. apt isn't going on a configuration file killing spree if you don't tell it to do that (and I am not sure how I would tell it to do that even if I wanted it…), but well, no, there is no difference between a package being removed with 'remove' and a package being removed thanks to dependencies (like Conflicts) as this is rather arbitrary difference. Installing a different MTA is probably as much a sentient decision as removing an MTA - and you have agreed to all these actions, so they have your official blessing… apt-get btw doesn't do an automatic remove in dist-upgrade by default, so none of the removes you see are in fact any more automatic than the installation of new packages - it is simply needed and part of the job description of a package manager. We have a apt-get autoremove for removing packages apt things might not be needed anymore. aptitude does run it by default. Best regards David Kalnischkies signature.asc Description: Digital signature
Re: Solutions for the Apache upgrade hell
On 2014-07-16 13:46:12 +0200, Guillem Jover wrote: On Wed, 2014-07-16 at 11:41:25 +0200, Vincent Lefevre wrote: On 2014-07-13 13:17:24 +0200, Arno Töll wrote: Unfortunately it turns out, that /a lot/ of people use aptitude --purge-unused safe-upgrade, or the apt equivalent apt-get dist-upgrade --purge which causes dpkg to purge the user's configuration, in particular enabled modules, during the upgrade because apache2.2-common disappears in that step. [...] Is there any reason why apt-get/aptitude removes the config files just after the package is removed, and not at the end of the upgrade process? IMHO, doing the later is safer and would solve this problem with Apache. It just calls dpkg with --purge. But what I meant is that it could do 2 passes: one without --purge, and a second one with --purge on the removed packages. Or... Something that would also fix this issue (among other upgrade problems) is using dpkg “transactions”: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=579790#82 Yes! -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717010710.ga26...@xvii.vinc17.org
Re: Solutions for the Apache upgrade hell
On 2014-07-16 14:28:00 +0200, David Kalnischkies wrote: On Wed, Jul 16, 2014 at 11:36:32AM +0200, Vincent Lefevre wrote: I do that too. I haven't seen any official documentation saying that this is a bad thing to do. aptitude actively warns against it as highlighted in this thread. Wrong! I purge removed packages almost all the time with aptitude, and I've never seen any warning! Official documentation also doesn't say that running 'rm -rf --no-preserve-root /' is a bad thing, Silly comparison. 'rm -rf --no-preserve-root /' does what it does: remove everything. When I purge packages, I just expect config files to be purged, not break the system! -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717011735.gb26...@xvii.vinc17.org
Re: Solutions for the Apache upgrade hell
Hi Arno, * Arno Töll a...@debian.org [140713 13:25]: [..] To summarize the bug reports: The problem is, that Apache package maintainers at that time decided, that third party modules shall depend on apache2.2-common, by guaranteeing ABIs remain stable as long as the package name does not change. [..] Unfortunately, apache2.2-common also contains conffiles and configuration file handling in postinst/postrm ... I spent a lot of time to properly transition to a new state with conffiles/configuration separated from ABI handling, and this works well enough for regular updates by now. Unfortunately it turns out, that /a lot/ of people use aptitude --purge-unused safe-upgrade, or the apt equivalent apt-get dist-upgrade --purge which causes dpkg to purge the user's configuration, in particular enabled modules, during the upgrade because apache2.2-common disappears in that step. Those people end up with effects as described in the bugs outlined above, for example with incomplete installations because our maintainer scripts had no chance to properly detect the state of the /etc/apache2 directory before the upgrade. This gives us three possibilities which all have unwanted side effects (unless you come up with an idea that all of us makes happy). I'm writing to this list in hope that someone has a very smart idea to make everyone happy, or express your support for either alternative to give us some insights what people think would be the best alternative. * Ignore the problem, and refer to the manpage of aptitude without proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING. The bad news is, we can't tell this before it's too late, such as in a NEWS file - and we know, everybody reads release notes too, right? I'm expressing support for this, and/or your second option. Any non-trivial setup will need config changes anyway, and any sane person already uses version control for /etc + config management for such setups. C. -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717012128.gb17...@sx.home.zeha.at
Re: Solutions for the Apache upgrade hell
On 2014-07-17 03:21:28 +0200, Christian Hofstaedtler wrote: * Arno Töll a...@debian.org [140713 13:25]: * Ignore the problem, and refer to the manpage of aptitude without proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING. The bad news is, we can't tell this before it's too late, such as in a NEWS file - and we know, everybody reads release notes too, right? I'm expressing support for this, and/or your second option. Any non-trivial setup will need config changes anyway, and any sane person already uses version control for /etc + config management for such setups. Actually the problem is not the data loss. The problem is the upgrade failure. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140717020211.gc26...@xvii.vinc17.org
Re: Solutions for the Apache upgrade hell
Hi Arno, On Sun, Jul 13, 2014, at 13:17, Arno Töll wrote: Hello, we've got a problem with Apache that causes problems during upgrades (e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4 changed ABIs, so that we need to ensure that dpkg properly removes packages linking against the obsolete ABIs at upgrade time. This is the first time this happened since Debian Etch, so this brings a problem to the spotlight, that hasn't been one for a long time. To summarize the bug reports: The problem is, that Apache package maintainers at that time decided, that third party modules shall depend on apache2.2-common, by guaranteeing ABIs remain stable as long as the package name does not change. This is, so far policy compliant. However, by now ABIs did change and we were forced to rename the package (we did so, by providing a virtual API package third parties must depend on. At time of writing this is apache2-api-20120211). Unfortunately, apache2.2-common also contains conffiles and configuration file handling in postinst/postrm ... I spent a lot of time to properly transition to a new state with conffiles/configuration separated from ABI handling, and this works well enough for regular updates by now. Unfortunately it turns out, that /a lot/ of people use aptitude --purge-unused safe-upgrade, or the apt equivalent apt-get dist-upgrade --purge which causes dpkg to purge the user's configuration, in particular enabled modules, during the upgrade because apache2.2-common disappears in that step. Those people end up with effects as described in the bugs outlined above, for example with incomplete installations because our maintainer scripts had no chance to properly detect the state of the /etc/apache2 directory before the upgrade. This gives us three possibilities which all have unwanted side effects (unless you come up with an idea that all of us makes happy). I'm writing to this list in hope that someone has a very smart idea to make everyone happy, or express your support for either alternative to give us some insights what people think would be the best alternative. * Add a apache2.2-commmon transitional package. This gives us a chance to inspect /etc/apache2 in spite of --purge-unused and properly transition to Apache 2.4. HOWEVER, this has the nasty side effect that modules ABIs are considered compatible as far as dpkg is concerned. Therefore, old module packages aren't forced to be removed and this breaks at runtime when people try to start their upgraded web server with incompatible modules. As a workaround we could add a versioned Breaks for all modules in Wheezy (~ 75) in the apache2.2-common transitional package, and in addition for packages that existed in Squeeze or Etch only (no, really). That said, this still won't help for third party modules outside Debian which people might use (and to my best knowledge, they do a lot) and it's generally problematic in view of the policy with respect to library packaging (even though we're not a library strictly speaking) This + BIG FAT WARNING in release notes seems to be the best option to me. People's configuration will probably break anyway due custom configuration files, etc. or manually compiled modules[1][2]. Also if people have custom modules that will get removed in the upgrade, they wouldn't want to start the apache without those modules anyway - this could have all kind of security implications - exposing the raw source files of interpreted languages, etc. 1. As an option you can walk through all enabled modules in apache2.4 postinst and detect incompatible ABI in /usr/lib/apache2/modules/*.so files. 2. As a thought did you think about moving the modules under /usr/lib/apache2/20120211/ (e.g. similar to what PHP has). You still have time for that and it would make the transition easier in the future (also with third party modules). Cheers, -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405325501.4775.141318941.5caff...@webmail.messagingengine.com
Re: Solutions for the Apache upgrade hell
h01ger wrote: I've never used upgrade --purge _in one step_ and I don't think it's a particularily smart idea at all. But if people want to shoot themselves in The --purge is a no-op with upgrade. But I normally use apt-get --purge dist-upgrade both to upgrade across distros and to stay within one distro (or sid), because otherwise I get issues: * Running upgrade before dist-upgrade sometimes doesn't get the dependencies right * Running dist-upgrade without --purge will keep packages in 'rc' state around, which a later APT call will not even recognise; you need to manually dpkg --purge pkg1 pkg2 ... to get rid of them Recently, my favourite has become: apt-get --purge dist-upgrade --auto-remove pkgtoinstall pkgtoremove- This combines the upgrade, the auto-remove (in virtually all cases), installation or removal of packages, and giving hints (by naming packages explicitly to keep or remove) to the dependency resolver, plus no 'rc' state packages lying around. (Thanks mvo for adding it!) bye, //mirabilos -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/lq05q1$6m5$3...@ger.gmane.org
Re: Solutions for the Apache upgrade hell
Le dimanche 13 juillet 2014 à 15:28 +0200, Arno Töll a écrit : Moving them to apache2 package would mean you won't have to move them again in the upgrade to apache 2.4, but it would create a new and circular dependency of apache2.2-common on apache2. Given that apache2.2-common already depends on apache2.2-bin and there exists a transitional package in jessie it might be a better candidate. Then you would have to move it again in the jessie package, but I'm afraid there aren't any easy solutions. Pretending the Release Team would allow us to do that (Frankly, I wouldn't dare to ask :p) thee are two caveats with that approach that would make it very hard and complicated because our historic heritage dating back to Etch days again. [Not a good idea to move them to apache2] [Not a good idea to move them to apache2.2-bin either] How about creating a new apache2-config package just to move these configuration files? -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1405339534.19738.6.ca...@kagura.malsain.org
Re: Solutions for the Apache upgrade hell
bofh80 dixit:
apt-get --purge dist-upgrade
How does this now translate to over the new apt full-upgrade?
I do not use “the new apt ” anything command. It is purely optional,
and you can use apt-cache and apt-get as you are used to.
apt-get --purge dist-upgrade --auto-remove pkgtoinstall pkgtoremove-
Could you give me an example of this? assuming that pkgtoinstall and
pkgtoremove are place markers for actual package names?
Yes.
Something like this:
“apt-get --purge dist-upgrade pinentry-curses pinentry-gtk2- xulrunner-17.0-”
This means: do a dist-upgrade, but purge pinentry-gtk2 and install
pinentry-curses during it (like first but better, dependency-wise)
and do not even bothering upgrading xulrunner-17.0 since I no longer
need it anyway.
and also is the - at the end intentional? (i might be wrong about the
markers, i'm not sure, hence the question)
The hyphen-minus at the end means “remove, not install, this package”.
It also works like “apt-get install foo bar- baz bla-”.
nb. i sent this directly to you rather than the list because i wasn't sure
if it was offtopic, feel free to mail it back to the list.
List works for me…
On 14 July 2014 09:53, Thorsten Glaser t...@debian.org wrote:
http://www.afaik.de/usenet/faq/zitieren/ please don’t top-post
or full-quote.
Thanks,
//mirabilos
--
Wish I had pine to hand :-( I'll give lynx a try, thanks.
Michael Schmitz on nntp://news.gmane.org/gmane.linux.debian.ports.68k
a.k.a. {news.gmane.org/nntp}#news.gmane.linux.debian.ports.68k in pine
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/pine.bsm.4.64l.1407141317290.8...@herc.mirbsd.org
Re: Solutions for the Apache upgrade hell
Thorsten Glaser t...@debian.org writes:
* Running dist-upgrade without --purge will keep packages in 'rc'
state around, which a later APT call will not even recognise;
you need to manually dpkg --purge pkg1 pkg2 ... to get rid
of them
I use apt dist-upgrade normally and then, periodically, run:
dpkg --get-selections | grep deinstall | awk '{ print $1 }' \
| xargs dpkg --purge
This is obviously somewhat unsafe. It would be neat to have a tool that
would do this properly without involving dodgy greps that might match
package names and other obvious issues. It's not particularly hard to
turn this rune into a real script with error checking, but it would be
nice to have this functionality built into apt somehow, but to not have to
do it at the same time as the upgrade due to issues such as those on this
thread.
--
Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87mwcb51dv@windlord.stanford.edu
Re: Solutions for the Apache upgrade hell
On 2014-07-14 18:52 +0200, Russ Allbery wrote:
Thorsten Glaser t...@debian.org writes:
* Running dist-upgrade without --purge will keep packages in 'rc'
state around, which a later APT call will not even recognise;
you need to manually dpkg --purge pkg1 pkg2 ... to get rid
of them
I use apt dist-upgrade normally and then, periodically, run:
dpkg --get-selections | grep deinstall | awk '{ print $1 }' \
| xargs dpkg --purge
This is obviously somewhat unsafe. It would be neat to have a tool that
would do this properly without involving dodgy greps that might match
package names and other obvious issues. It's not particularly hard to
turn this rune into a real script with error checking, but it would be
nice to have this functionality built into apt somehow, but to not have to
do it at the same time as the upgrade due to issues such as those on this
thread.
Note that aptitude can already do this, this is what I run regularly:
# aptitude purge ~c
Getting at least some of aptitude's extensive search patterns[1] into apt
would certainly be very useful.
Cheers,
Sven
1. http://aptitude.alioth.debian.org/doc/en/ch02s04s05.html
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87k37foohf@turtle.gmx.de
Re: Solutions for the Apache upgrade hell
On Mon, Jul 14, 2014 at 09:52:12AM -0700, Russ Allbery wrote:
I use apt dist-upgrade normally and then, periodically, run:
dpkg --get-selections | grep deinstall | awk '{ print $1 }' \
| xargs dpkg --purge
This is obviously somewhat unsafe. It would be neat to have a tool that
would do this properly without involving dodgy greps that might match
package names and other obvious issues.
Slightly better might be
dpkg --get-selections | awk '{if ($2 == deinstall) { print $1 } }'
though I see there's a way to say this in aptitude to directly say what
you want.
Jeff
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140714172947.gb6...@unpythonic.net
Re: Solutions for the Apache upgrade hell
Jeff Epler wrote:
Russ Allbery wrote:
I use apt dist-upgrade normally and then, periodically, run:
dpkg --get-selections | grep deinstall | awk '{ print $1 }' \
| xargs dpkg --purge
This is obviously somewhat unsafe. It would be neat to have a tool that
would do this properly without involving dodgy greps that might match
package names and other obvious issues.
Slightly better might be
dpkg --get-selections | awk '{if ($2 == deinstall) { print $1 } }'
though I see there's a way to say this in aptitude to directly say what
you want.
As long as we are tuning... I prefer grep-status for this. This
returns a list of package names of packages that have been removed but
still have config files behind. Those in the dpkg rc state.
grep-status -sPackage -n -FStatus deinstall ok config-files
-s print only that field, otherwise print full paragraph
-n no print field name, just value
-F field to search
If that list is reasonable then this. It just feels more precise.
dpkg --purge $(grep-status -sPackage -n -FStatus deinstall ok config-files)
Don't forget about the deborphan and orphaner packages either.
Bob
P.S. AWK is design to operate by fields. I am sure I am not the only
one who saw the if $2 above and thought it should be like this:
awk '$2==deinstall{print$1}'
signature.asc
Description: Digital signature
Solutions for the Apache upgrade hell
Hello, we've got a problem with Apache that causes problems during upgrades (e.g. #716880, #752922, #711925). In short, the issue is that Apache 2.4 changed ABIs, so that we need to ensure that dpkg properly removes packages linking against the obsolete ABIs at upgrade time. This is the first time this happened since Debian Etch, so this brings a problem to the spotlight, that hasn't been one for a long time. To summarize the bug reports: The problem is, that Apache package maintainers at that time decided, that third party modules shall depend on apache2.2-common, by guaranteeing ABIs remain stable as long as the package name does not change. This is, so far policy compliant. However, by now ABIs did change and we were forced to rename the package (we did so, by providing a virtual API package third parties must depend on. At time of writing this is apache2-api-20120211). Unfortunately, apache2.2-common also contains conffiles and configuration file handling in postinst/postrm ... I spent a lot of time to properly transition to a new state with conffiles/configuration separated from ABI handling, and this works well enough for regular updates by now. Unfortunately it turns out, that /a lot/ of people use aptitude --purge-unused safe-upgrade, or the apt equivalent apt-get dist-upgrade --purge which causes dpkg to purge the user's configuration, in particular enabled modules, during the upgrade because apache2.2-common disappears in that step. Those people end up with effects as described in the bugs outlined above, for example with incomplete installations because our maintainer scripts had no chance to properly detect the state of the /etc/apache2 directory before the upgrade. This gives us three possibilities which all have unwanted side effects (unless you come up with an idea that all of us makes happy). I'm writing to this list in hope that someone has a very smart idea to make everyone happy, or express your support for either alternative to give us some insights what people think would be the best alternative. * Ignore the problem, and refer to the manpage of aptitude without proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING. The bad news is, we can't tell this before it's too late, such as in a NEWS file - and we know, everybody reads release notes too, right? * Add a apache2.2-commmon transitional package. This gives us a chance to inspect /etc/apache2 in spite of --purge-unused and properly transition to Apache 2.4. HOWEVER, this has the nasty side effect that modules ABIs are considered compatible as far as dpkg is concerned. Therefore, old module packages aren't forced to be removed and this breaks at runtime when people try to start their upgraded web server with incompatible modules. As a workaround we could add a versioned Breaks for all modules in Wheezy (~ 75) in the apache2.2-common transitional package, and in addition for packages that existed in Squeeze or Etch only (no, really). That said, this still won't help for third party modules outside Debian which people might use (and to my best knowledge, they do a lot) and it's generally problematic in view of the policy with respect to library packaging (even though we're not a library strictly speaking) * Treat the upgrade as new install in our maintainer scripts when --purge-unused was used (side question: Any idea how to reliably and properly detect that case, as the binary package name changed and it's well possible that in Wheezy apache2.2-common is installed, but not apache2 because of weird(tm) packaging)? This would not preserve user's choices in regard of enabled/disabled modules and thus be a borderline policy violation, too. What would you do in our situation? Side note 2: We kinda expected this situation and added a trapdoor in Wheezy [1], but it turned out, that even that is not good enough to prevent havoc with --purge-unused. [1] http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/apache2.2-common.postrm;h=bbe9f740b81cf8af64412f7ba6aace119dd159ad;hb=refs/heads/wheezy#l5 -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Solutions for the Apache upgrade hell
Hi Arno, On Sonntag, 13. Juli 2014, Arno Töll wrote: * Ignore the problem, and refer to the manpage of aptitude without proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING. seems right to me, given the alternatives you describe. I've never used upgrade --purge _in one step_ and I don't think it's a particularily smart idea at all. But if people want to shoot themselves in the feet, we should tell them that it might hurt, but then... let them. Same for not reading release notes, if someone wants to act stupid... ;-) cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: Solutions for the Apache upgrade hell
At Sun, 13 Jul 2014 13:17:24 +0200, Arno Töll wrote: What would you do in our situation? Side note 2: We kinda expected this situation and added a trapdoor in Wheezy [1], but it turned out, that even that is not good enough to prevent havoc with --purge-unused. It's not really ideal either, but another option would be doing an update in the next wheezy point release preparing this migration. For example moving the configuration files from apache2.2-common to apache2 or apache2.2-bin in wheezy shouldn't cause any problem and after the files have been moved apache2.2-common can be safely purged during upgrade. Moving them to apache2 package would mean you won't have to move them again in the upgrade to apache 2.4, but it would create a new and circular dependency of apache2.2-common on apache2. Given that apache2.2-common already depends on apache2.2-bin and there exists a transitional package in jessie it might be a better candidate. Then you would have to move it again in the jessie package, but I'm afraid there aren't any easy solutions. Kind regards, Jeroen Dekkers -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87r41pxv50.wl%jer...@dekkers.ch
Re: Solutions for the Apache upgrade hell
Hi Jeroen, On 13.07.2014 15:09, Jeroen Dekkers wrote: It's not really ideal either, but another option would be doing an update in the next wheezy point release preparing this migration. For example moving the configuration files from apache2.2-common to apache2 or apache2.2-bin in wheezy shouldn't cause any problem and after the files have been moved apache2.2-common can be safely purged during upgrade. thanks for bringing this up. We had discussed this a while back, but I forgot to list it in the provided alternative choices. Moving them to apache2 package would mean you won't have to move them again in the upgrade to apache 2.4, but it would create a new and circular dependency of apache2.2-common on apache2. Given that apache2.2-common already depends on apache2.2-bin and there exists a transitional package in jessie it might be a better candidate. Then you would have to move it again in the jessie package, but I'm afraid there aren't any easy solutions. Pretending the Release Team would allow us to do that (Frankly, I wouldn't dare to ask :p) thee are two caveats with that approach that would make it very hard and complicated because our historic heritage dating back to Etch days again. It's well possible, that people have apache2.2-common installed, but not apache2. In Wheezy and earlier apache2 is very much an empty pseudo package nothing depends on. Unless the user did apt-get install apache2 they won't end up with it as a dependency. This is commonly the case if you did apt-get install php5 for example. We cannot move conffiles to apache2.2-bin either, because Gnome for example depends on that package (don't ask) and it does it's own configuration completely detached from Debian packaging and Debian configuration. Therefore, people that don't use Apache on their own have that package installed, too. -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Re: Solutions for the Apache upgrade hell
Hey there. On 07/13/2014 08:36 AM, Holger Levsen wrote: Hi Arno, On Sonntag, 13. Juli 2014, Arno Töll wrote: * Ignore the problem, and refer to the manpage of aptitude without proper fix etc. which clearly says THIS OPTION CAN CAUSE DATA LOSS! DO NOT USE IT UNLESS YOU KNOW WHAT YOU ARE DOING. seems right to me, given the alternatives you describe. I've never used upgrade --purge _in one step_ and I don't think it's a particularily smart idea at all. But if people want to shoot themselves in the feet, we should tell them that it might hurt, but then... let them. Same for not reading release notes, if someone wants to act stupid... ;-) I agree in every single aspect with Holger. An upgrade --purge sounds to me like: Upgrade and start with fresh configuration. I usually proceed with dist-upgrade, then autoremove --purge to keep things neat. Again, should a release note poping up right in front of your eyes be ignored, there's not much to prevent you from damaging your system if you don't really care about it. Not really trying to act rude here (and I'm sorry if it seems so, just can't figure out another way to put it simple), but package management systems are, IMHO, intended to facilitate the access and installation of packages which are part of the distro/release while preventing us from facing dependancy-hell-like situations, they're not intended to be fool-proof, as it requires administrative privileges, therefore expecting that you *really* know what you're doing. Cheers, Fabiano. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53c2edbe.2060...@itgen.com.br
