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

Re: package configuration design

 [ In Debian Devel ]
>>>>> "fog" == fog  <fog@irfmn.mnegri.it> writes:

    fog> I mean that, during the configuration phase, the user may
    fog> decide to postpone the configuration of a package (maybe she
    fog> wants to read some docs but the docs aren't installed until
    fog> the package is unpacked...).

 That brings up another issue.  Suppose I want to install only the
 programs and their conffiles + extrafiles and control info, but not
 the documentation and/or man pages?  (Like when /usr/man is an nfs
 mount, or this box is a server and all the docs are on my
 workstation.).  I guess there should also then be a way to install
 _only_ the man pages and/or docs also.

 I don't manage a network and have never done so.  Someone with
 experience with that sort of thing needs to please speak on this;
 I've a vague understanding of what's involved, as far as what could
 be profitably nfs mounted vs installed on each workstation or node.

 I seem to recall this being brought up in discussions about `apt'
 (aka deity).  I hope this is planned and slated for implementation.
 Anyone know?

 Another thing to do would be to offer a config option to have the
 installer tools gzip things in /usr/doc that are not packaged in
 zipped form, such as html...  perhaps this could be an `apt' plug-in,
 only available after installing a package that adds the necessary
 Apache configs as well as the cgi-bin scripts required for unzipping
 the html prior to service.  (See below)  I suppose we could add
 another virtual package for this feature, if another web server, such 
 as `boa', supported on the fly decompression like this.

 It occurs to me that this new package might then need to modify the
 apache conffiles.  Can apache be told to read a set of files from a
 config.d/ directory?  This feature would be useful anyway.  I think
 it would make managing the Apache configuration of a large site a
 little simpler.

 I have a cron job that runs once a week and gzips all of the new html
 in /usr/doc/**.  I use the extension `.htmlgz' for the compressed
 files, and the attached Apache configuration.  This method has the
 great advantage that the documents can be stored in compressed form,
 yet none of them need to be stream editted to fixup the contained
 URL's, since the web server performs these sendmail-like rewrites in
 order to find the right file.  The canonical URL will locate the
 compressed version automagicly, and completely transparently.

 It could optionally be served as `Content encoding:
 application/gzip', but Windows 9X browsers can't deal with it.  I
 think it's possible to configure apache to serve it that way instead
 of gunzipping prior to service using a shell script and zcat.

Attachment: zcat-html
Description: Binary data

Attachment: access.conf
Description: Binary data

Attachment: srm.conf
Description: Binary data

Reply to: