Re: Status of Debian Policy
In article <[🔎] Pine.LNX.3.96.970615170603.1197A-100000@klee>,
Christian Schwarz <schwarz@monet.m.isar.de> writes:
> All packages that provide HTML documentation should register these
> documents to the menu system, too. Check out section section 4.1, `Web
> servers and applications' for details.
Is that as well as registering with dwww?
Currently some packages do one and some the other.
> 2. Build a shared library ``libdebian'', that contains
> functions to lock, unlock, and test a file according to the
> locking method we want to use. This library should simplify
> the work of the MUA and MTA maintainers that need to adopt
> their packages. They should link their programs against
> this library and call the appropriate functions.
Would programs _have_ to use this library, or is implementing the same thing
in acceptable? The latter has problems in that it forces us to keep the same
method, but I don't want to see lots of #ifdef debian appearing in the
original source; apart from anything else it doesn't look good being
non-standard even if what we do is superior.
> If we have a consensus about this, we could include a ``good example''
> for a ``/usr/doc/*/README.debian'' file.
>
> I propose that the following infos are listed in this file:
>
> - Name and email address of current Debian maintainer
> - specification about where to get the upstream sources
> - short description of all major changes to the program
> (for example, new command line options, changed locking
> mechanism, major bug fixes, etc.)
> - URL of ``official home page'' if there is one (optional)
Most of this is included in the /usr/doc/${package}/copyright files; why
duplicate it in another file? I can't see any point in a README.debian
except to describe major user visible changes.
> IMHO, we should give some guidelines about how to install cron jobs,
> i.e.
> - don't touch /var/spool/cron/crontabs
> - don't touch /etc/crontab
> - you may install files in /etc/cron.{daily,weekly,monthly}
> if certain rules are fulfilled (cf. bug #8814)
What should you do if you want your job to run at an interval other than
daily weekly or monthly?
> - .info files can be converted into HTML on-the-fly by the CGI
> script "info2www". However, the output of ``texi2html'' is
> much better. Should we ship only HTML by default and put
> .info in a seperate package? (cf. bug #7890)
I'd prefer to see HTML ones in a separate package and info included by
default. Like it or not, info is the standard now; I don't want my hard disc
full of HTML copies of info documents.
> - how "large" may doc files be until they are moved into a
> seperate package?
I don't think just the size should be the deciding factor, so much as how
difficult it is to use the package without documentation. Obviously size is
a factor but I don't think simply putting a limit on the size is very
useful.
.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: