Results from Policy Weekly #5
The last policy weekly posting was a great success! The posting contained
15 topics for approval, and 14 of these have been approved (i.e., they
will be included in the Policy Manual and the other manuals shortly).
Thanks to all who participated in the discussions and who sent me private
notes about the different topics!
Since I think some of you might be intrested in the exact results I've
included my current list below. Comments are welcome, but please reply to
the debian-policy list only or send me a private mail.
(Note, that the list was done in a few minutes. I hope you get the meaning
of all abbreviated sentences :) If not, just ask.)
Thanks,
Chris
------------cut-here--------------
Results from Policy Weekly #5
=============================
* 1: Bash vs Bourne shell
approved
- change "of course" in "as in the case of bash" in policy text
- after hamm is released /bin/sh will be managed through `alternatives'
* 2: Maintainer's reaction on non-maintainer uploads
approved
- fixed text to read:
* (As current policy says) the person doing the non-maintainer upload
should send a bug report to the bug tracking system explaining
his/her
changes. This is extremly important so that the usual maintainer gets
notified about the interim release.
* The normal maintainer should do at least one of
o apply the diff
o read the diff and decide on each part of it themselves
o read the description of the changes to the next upstream
version and ensure that they fix each
problem that was fixed in the non-maintainer release.
* If the non-maintainer upload fixes some bugs, the bugs should not be
closed. However, the person making the non-maintainer release should
send a short message to the bug tracking system to all the fixed bugs
explaining that they have been fixed. This way, the maintainer and
other people will get notified about that.
- implement new severity level `fixed'? (cf. other mail I sent to
debian-policy a few minutes ago)
* 3: How packages can register cron jobs
approved
* 4: Gzipped symlinks
approved
* 5: Standardized handling of /etc/init.d script options
approved
- don't list unsupported options in the syntax line
- if the daemon(s) handles a `reload' automatically (i.e., in case of
cron) the scripts should behave as if everything was successful (i.e., no
messages; exit code 0)
* 6: Consistent handling of the Backspace and Delete keys
approved
* 7: Linking shared libraries with -lc
approved
- fix text to state that shared libs are always linked dynamically against
each other, but dependency information is only included if `-lc' is used
* 8: How to do mass-bug-reports correctly
approved
- apply fixes from Chris Fearnley (grammatical fixes)
* 9: Non-interactive build process of packages
approved
- fix text to refer only to `required targets' (other makefile targets
may require interaction)
* 10: System-wide environment variables used for program configuration
approved
- Add note: if a program can not run without some environment variables
and we cannot fix this program for some reason (e.g., we don't have the
source code) then you should install the binary in /usr/lib/<pkg> and
install a "wrapper" shell script like this:
---cut-here---
#!/bin/sh
BAR=/var/lib/fubar
export BAR
exec /usr/lib/foo/foo "$@"
---cut-here---
* 11: Policy on stripping static libraries
not approved, yet--still to many different opinions
* 12: New upload procedure
approved with following additions:
- a `source upload' will be determined by looking at the "Architecture"
field of the .changes file
- dinstall will _not_ check for `~/.changes-template' before sending
the announcement (-> the user can add some text to the .changes file via
dpkg-genchanges on his/her own system more easily)
- fix regex pattern: change \( into (, etc.
- allow "fixes:bug#xxx" tags to be wrapped over several lines (currently,
`debian-changelog-mode' wraps long lines)
- when the announcement is sent to debian-devel-changes, set `From' header
field to the uploader's email address, not `dinstall@debian.org'
- only dinstall will scan the changelog entry for fixes fields, not
dpkg-genchanges (perhaps a new option for dinstall could be used for
maintainers to check the changelog; dinstall should mention closed bug
reports in install report mail that is sent to the maintainers)
- only close bugs if person-listed-in-changelog-entry == maintainer,
otherwise assign severity to `fixed' (cf. my other mail)
- change `Maintainer:' field in upload to something more appropriate
(currently, not the maintainer is listed in this field, but the
`Uploader')
- use full-qualified email address `@bugs.debian.org' in example
* 13: New virtual packages
libc-dev approved
pascal-compiler approved, but put on hold since there is no use for it
* 14: Games using X11
approved
* 15: Package versions based on dates
approved
- we'll suggest the format `YYYY-MM-DD' for our own packages
- we'll explicitely _not_ suggest to bother the upstream maintainer
changing the version number if it's not `YYYY-MM-DD'; however it's
up to the maintainers to decide, whether they should contact the upstream
maintainer about that (depending on `how good' the relation is :)
* 16: Use of /usr/src
my suggestion `to leave policy unchanged' has been approved
-- Christian Schwarz
Do you know schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian GNU/Linux? schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Visit PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
http://www.debian.org http://fatman.mathematik.tu-muenchen.de/~schwarz/
--
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: