On 2013-05-13 14:37:28 +0100, Philip Hands wrote: > Vincent Lefevre <vinc...@vinc17.net> writes: > > There's also a problem that the man pages are in the package: > > > > $ dpkg -L apache2.2-common | grep /man/ > > /usr/share/man/man8 > > /usr/share/man/man8/apache2.8.gz > > /usr/share/man/man8/a2ensite.8.gz > > /usr/share/man/man8/apache2ctl.8.gz > > /usr/share/man/man8/a2enmod.8.gz > > /usr/share/man/man8/apachectl.8.gz > > /usr/share/man/man8/a2dissite.8.gz > > /usr/share/man/man8/a2dismod.8.gz > > I suppose you could file a wishlist bug requesting a -doc package, but > I'd expect that to be marked wontfix, since the effort is probably not > justified by the size of audience that would appreciate such a change.
There's already a -doc package, but only with a HTML manual, while the man pages also provide additional information (and in general, I prefer the man pages). > > There's no way to read this documentation first or keep it > > (this is useful if one wants to write/maintain a script that > > tests whether apache2 is available or not, for instance). > > "no way" is a bit strong. > > There are several ways of getting at the man pages without installing > apache. > > If you're OK with it just being the manpage from current testing: > > http://man.cx/apache2(8) I'm on unstable, but well... Actually the main problem is that it requires an Internet access, something I don't always have. > If you must see the man page from a particular package: > > dget apache2.2-common > mkdir -p ./tmp/apache2.2-common > dpkg -X apache2.2-common_2.2.22-13_amd64.deb ./tmp/apache2.2-common It's simpler to install the package (or not remove it) and disable the daemon. [...] > Returning to your original point, it's not even as though it's hard to > disable an installed service on Debian. I normally do that by stopping > the service and then adding something like this as the second line of > the init.d script: > > exit 0 # disabled rather than removed in order to keep the man pages around > -- pgh 2013-05-23 > > which (particularly when committed to etckeeper with a similar message) > makes sure that the reason for deviating from the norm is clear to > others (and to my forgetful self) in future. > > Since the init.d script is a conffile, you get reminded of your decision > to disable the service on every upgrade, which often saves a lot of head > scratching. But this prevents init.d script updates. I'd rather use one of the standard methods. > You seem to want the system to guess what's in your head, which may be > fine some of the time, but if you later install another package that, > unknown to you, has acquired some sort of web interface in the latest > version, then presumably that would result in the system guessing > (wrongly) that apache should be automatically re-enabled for you. That's in general what I want if this is intended by the package (there should be documentation and a way to switch this on and off). > I can do without surprises like that. > > Actually, I just installed sensord to see what you were getting at with > your claim that you wanted apache to stop running if you removed > sensord. I see no plumbing in sensord that is intended to provoke > apache to run, or even help apache know that there's anything for it to > publish (so no apache.conf snippet, no automatically created directory > for the RRD images). The postrm script only does an update-rc.d remove > on purge, and certainly does not have anything to remove RRD graphs, I'm aware of them, so that I would remove them (it's bad to keep something obsolete). Note that however one isn't necessarily aware which services need Apache. > so how apache is supposed to guess that you don't want to publish > them any more just because you removed a vaguely related package is > a bit of a puzzle. What I mean is that there could be some user directives to do that. For instance, most init.d scripts have: test -f $DAEMON || exit 0 One could imagine the same thing but with testing directories... Something like in the /etc/default/ file: test -f some_dir || ENABLED=0 But this method needs an "ENABLED" variable! -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://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: http://lists.debian.org/20130513142658.gn26...@ioooi.vinc17.net