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

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.) 




Results from Policy Weekly #5

* 1: Bash vs Bourne shell
- 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
- 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
     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

* 4: Gzipped symlinks

* 5: Standardized handling of /etc/init.d script options
- 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

* 7: Linking shared libraries with -lc
- 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
- apply fixes from Chris Fearnley (grammatical fixes)

* 9: Non-interactive build process of packages
- fix text to refer only to `required targets' (other makefile targets
may require interaction)

* 10: System-wide environment variables used for program configuration
- 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:
export BAR
exec /usr/lib/foo/foo "$@"

* 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
- 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

* 15: Package versions based on dates
- 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/

Reply to: