In article <[EMAIL PROTECTED]>, Christian Schwarz <[EMAIL PROTECTED]> 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.