[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: jessie release goals



On 2013-05-13 14:37:28 +0100, Philip Hands wrote:
> Vincent Lefevre <vincent@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 <vincent@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)


Reply to: