On Thu, May 02, 2002 at 10:09:11AM +0100, Julian Gilbey wrote:
> Part I: The Debian Archive
> 1: DFSG and the sections of the archive (free, non-free, contrib, non-us)
^^^^^^^^
"Components" is a much better word to use here. (And is the word used
everywhere but -policy, just about)
> 2: The different distributions (stable, etc.)
I.2 is probably more properly done in the developer's reference, since
it doesn't impact how you go about constructing an ideal Debian package.
Priorities? Sections?
> Part II: Packages and metadata
> 3: Package structure (source, binary, arch-dep/indep)
> 4: Control fields: source package fields
> 5: Control fields: binary package fields
> 6: Package dependencies: binary packages
> 7: Package dependencies: source packages
>
> Part III: Packaging scripts and files
> 8: Maintainer scripts
> 9: Other miscellany: debian/rules, changelog, files, substvars, etc.
> 10: Configuration files
> 11: Shared libraries
changelogs? copyright files?
Perhaps something like:
1. Where your package should go
Archive: ftp-master / non-us (or not distributable?)
Component: main / contrib / non-free
Priority
Section
Architecture
Package naming + Versioning
2. How your package gets installed
Depends/Pre-Depends/Recommends/Suggests/Provides
Essential: yes?
preinst, postinst, prerm, postrm
debconf (.config, .templates)
configuration files
conffiles versus postinst
sharing configuration files amongst multiple packages
that aren't installed together
that are installed together
3. How your package gets built
source packages
debian/rules
Build-Depends:/Build-Conflicts:
changelog
what gcc options to use, environment variables to use
pointers to dpkg_shlibdeps, debhelper, etc?
4. Other general stuff
copyright file
file locations
/usr/share/doc
symlinks
users and groups
file permissions
dpkg-statoverride, and when packages should use it
init scripts (which runlevels, messages, how to write them)
cron jobs
menus
environment variables
don't expect them
$EDITOR || /bin/editor
$PAGER || /bin/pager
alternatives versus Provides/Conflicts
MIME stuff
/dev/*
user configuration files
log files
ptys, wtmp, utmp, lastlog
i18n/l10n
references for gettext, man pages, debconf
keyboard handling
misc security info
/tmp/races and how to avoid them
5. Special cases for when you're packaging...
...scripts
put a #! in them
/bin/sh for POSIX scripts
/bin/bash for bash scripts, but use /bin/sh if possible
t/csh scripts need deps on c-shell
perl scripts can only use stuff in perl-base
python scripts need deps on python
...internet servers
when to use inetd / standalone, how to offer the choice
how to use inetd
how to get /etc/services updated
...documentation
manpages?
info pages?
-doc package or include it inline?
should it go in /u/s/doc/foo-doc or /u/s/doc/foo?
what formats?
debian-doc
...C libraries
multiple packages, -fPIC, where headers go etc
...perl stuff
naming, depends, locations, etc
...python stuff
...emacs stuff
fancy scripts!
...fonts
X? tetex? truetype?
...games
/usr/games and /var/games reminder
system-wide scorefiles in /var/games
security policy - setgid not setuid
...MTAs & MDAs
mail-transport-agent
/var/mail, /etc/aliases, /usr/sbin/runq, etc
...webservers
what should http://localhost/doc do?
where should http://localhost/ point to?
where should http://localhost/cgi-bin/ point to?
...web services
CGI scripts
where should they be put?
how should they be setup so the admin can
choose not to enable them?
PHP stuff?
...X servers
(depends, provides)
...X clients
always enabled, rarely split into separate packages
/etc/X11/app-defaults
/usr/X11R6
Motif
...X terminal emulators
...X window managers
...would work out well?
> Then each section could either have the structure:
> Policy dictate s
> Discussion, useful information, guidelines, examples
> or we could merge them, and have policy dictates all in the form MUST,
> SHOULD, MAY, MUST NOT, etc., as in the RFCs.
I'm quite confident that trying to differentiate between requirements
and guidelines like this will turn out to be completely unhelpful and
a large waste of time, personally.
> (As far as RC issues
> goes, this could be marked by (RC) after the MUST/SHOULD/whatever,
> with a catchall at the start of policy that the final decision on what
> is RC rests with the release manager.)
As far as RC issues go, they'll be specified in an entirely separate
document, not maintained by the policy group.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``BAM! Science triumphs again!''
-- http://www.angryflower.com/vegeta.gif
pgp7DNmktuJuh.pgp
Description: PGP signature
