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

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

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: