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

Re: Working on debian developer's reference and "best packaging practices"

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
		Package naming + Versioning

	2. How your package gets installed
		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
		what gcc options to use, environment variables to use
		pointers to dpkg_shlibdeps, debhelper, etc?

	4. Other general stuff
		copyright file
		file locations
		users and groups
		file permissions
			dpkg-statoverride, and when packages should use it
		init scripts (which runlevels, messages, how to write them)
		cron jobs
		environment variables
			don't expect them
			$EDITOR || /bin/editor
			$PAGER || /bin/pager
		alternatives versus Provides/Conflicts
		MIME stuff
		user configuration files
		log files
		ptys, wtmp, utmp, lastlog
			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...
			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
			info pages?
			-doc package or include it inline?
			    should it go in /u/s/doc/foo-doc or /u/s/doc/foo?
			what formats?
		...C libraries
			multiple packages, -fPIC, where headers go etc
		...perl stuff
			naming, depends, locations, etc
		...python stuff
		...emacs stuff
			fancy scripts!
			X? tetex? truetype?
			/usr/games and /var/games reminder
			system-wide scorefiles in /var/games
			security policy - setgid not setuid
		...MTAs & MDAs
			/var/mail, /etc/aliases, /usr/sbin/runq, etc
			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
		...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.


Anthony Towns <aj@humbug.org.au> <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

Attachment: pgpWH6tOTyeq_.pgp
Description: PGP signature

Reply to: