As several people have expressed an interest in seeing Debian Policy
related announcements on this list, I am posting this rather long
summary of the state of old and decrepit policy proposals. Please follow
up to debian-policy or (preferably) to the individual entry in the BTS,
not debian-devel-announce!.
(This is a duplicate of a message previously sent to debian-policy; you
can safely skip it if you read it there. Of course, you can safely skip
it anyway: there will not be a test later.)
===================================================================
This is a summary of the status and disposition of many of the old
(> 1yr) debian-policy proposals. Only bugs marked as "fixed" were
considered; they were marked this way because they had been rejected or
hadn't had any action in several months ("stalled"). If you disagree
with my action, please comment and suggest an alternative. If desired,
re-open the bug while we discuss.
Each individual item has also been sent to the corresponding bug # in
the BTS. Please don't respond to this report; instead, reply to the
bug#@bugs.debian.org address so that the history of the discussion is
incorporated into the BTS.
========
Bug #23661: usr/doc should not be accessible through http servers by default
Summary: suggests that http://hostname/doc/ not be available by
default, except to localhost clients. "security through obscurity"
argument raised, but consensus seemed to be that making ones entire
installed program list, including version, available to the Internet
was perhaps pushing it a bit far. It was noted that later releases of
Apache and Boa restricted access, but that doesn't solve the problem
generally.It then went on to the "Well, there's a whole bunch of
services that shouldn't be available by default". Raul Miller seems to
have started examining a way to deal with this, but there's no further
note in the BTS after 22 Jun 2000.
Discussion: Policy currently says "HTML documents...can be referred to
as http://localhost/doc/package/filename";. This could be sufficient to
imply that access should, by default, be restricted to localhost, but
a guiding comment or footnote should probably be added. One question
is what to do about httpds that don't support access controls.
Action: I've submitted a new proposal that addresses only the httpd
issue that refers to this one.
========
Bug #27137: Clarification of non-free: packages encouraging donations
with claims about non-donation
Summary: Update policy to reflect change in definition of contrib
Discussion: None
Action: This has been incorporated into policy. I'm closing it.
========
Bug #27205: Daemons should run as root only if really needed
Summary: See title. Consensus was that this should part of the (as yet
unwritten) Debian Coding Guidelines rather than policy.
Discussion: None
Action: No change in status. It's being left open as a reminder.
========
Bug #30036: Including sub-policies (emacs, menu etc) in policy
Summary: Proposed incorporating sub-policies into policy
document. Nobody seemed to like this much; a counter-proposal of
including the sub-policy docs in the debian-policy .deb gained more
support. Lots of concern about mixing of technical details (e.g. how
to write a menu-method) with policy (e.g. what is the menu hierarchy).
Discussion: This seems to have come to consensus and agreement, as the
policy .deb currently contains mime-policy, menu-policy, and
perl-policy. No emacs-policy, but I'd guess that audience is small
enough there's no problem there. Presumably sub-policy writers will
submit their doc when it seems appropriate.
Action: close.
========
Bug #33826: Policy should discuss '.sh' suffixes on /etc/init.d files
Summary: Policy didn't say anything special about '.sh' scripts. After
a few disconnected replies (it seems that some, but not all, messages
from another discussion were being forwarded to this bug) it trailed
off. Julian Gilbey later asked for a proposed improvement to policy.
There were no replies.
Discussion: The current version of Policy includes the sentence "Also,
if the script name ends .sh, the script will be sourced in runlevel S
rather that being run in a forked subprocess, but will be explicitly
run by sh in all other runlevels" which would seem to resolve this bug
report. My reading of bug discussion leads me to believe there may
another issue: assumptions about sh == bash for those scripts (this
wasn't specifically discussed in the proposal, because at the time we
didn't explicitly support non-bash /bin/sh, IIRC).
Action: I'm going to close this one, but it might be a good idea to
address the sh vs. bash issue for '.sh' scripts in /etc/rcS.d.
========
Bug #36151: etc/init.d scripts should specify an explicit PATH
Summary: init.d scripts shouldn't depend on having PATH set in a
useful manner -- they should explicitly set the PATH. Not much
discussion in the bug logs, and most of the flame^H^H^H^H^Hdiscussion
took place on debian-devel. Result inconclusive. Last few notes
in BTS are that it should be part of the coding guidelines, not
policy
Discussion: No additional comments
Action: Retitle as "GUIDELINE" for future reminder.
========
Bug #41113: Naming Conventions for modules
Summary: Policy should consistent naming conventions for language
extension modules (perl, python and java were the examples under
discussion). Lots of suggestions, preferences and history, no
agreement or concrete proposal.
Discussion: Nothing added in over a year.
Action: close.
========
Bug #41902: Test suite proposal
Summary: An proposal for providing regression tests alongside the
Debian packages: what they should do, what they shouldn't do, etc.
No comments. No reply from submitter when pinged 6 months later.
Discussion: An interesting document, but apparently a dead
proposal. Since we do archive closed bug reports now, I'm just going
to close it.
Action: close
========
Bug #42554: A proposal for README.Debian
Summary: Proposed that a /usr/share/doc/package/README.Debian file
sanctioned and specified appropriate content. Some of that content
currently appears in the copyright file. Particular items that brought
objection were build time dependencies (now part of Build-Depends
et. al.) and compiler options (should be discussed in debian/rules if
necessary). Proposal also made the file required if upstream source
was modified; this also brought objections. Some noted that the
copyright file currently contains things completely unrelated to
copyright. AJ counter-proposed a policy mod that would move those items
to README.Debian. People seemed to like that better, but then
discussion died out.
Discussion: I like AJ's proposal, it makes perfect sense. However,
inertia seems against it. I may re-propose his mod.
Action: close
========
Bug #42870: every alternative should be usable
Summary: Packages that provide alternatives shouldn't hide the actual
program off in /usr/lib or somesuch. No comments or discussion
Discussion: This seems eminently sensible, but not really appropriate
for policy.
Action: Retitle as a [GUIDELINE] for future reference
========
Bug #42907: Policy should mention permissions of /dev/[dsp,audio,mixer]
Summary: Original bug report was claim that various sound tools should
be sgid audio. Maintainer correctly noted the reasons for the devices
being writable only group audio, and that making the binary sgid audio
would defeat that purpose. Re-assigned to Policy with the idea that
those reasons should be mentioned in policy.
Discussion: I don't think this is a policy issue at all. Various
device permissions are set for various reasons, and I don't think we
want or need to justify them in policy.
Action: close
========
Bug #43077: Remove the incompatibility argument from 5.1
Summary: (Note section is now 12.1) Policy requires that architecture
strings be of the form arch-os, and specifically forbids
arch-vendor-os, "since that would make our programs incompatible with
other Linux distributions". Submitter argues that this is
bogus. Single seconder of proposal contends that some programs
(e.g. Xemacs) require a three part spec string.
Discussion: I don't know enough about how these strings are used to
determine the desirability of this proposal, but figure if it was
important to those who cared, there would be some followup
effort. Re-open or resubmit if desired.
Action: close
========
Bug #43483: section 3.2 should not allow static user ids (except root=0).
Summary: (Note that section is now 10.2) We should require apps to
deal with non-statically allocated uids (e.g. no hardcoded
ids). Contention is that this is easy (only a few lines of code). One
seconder, and some discussion about what LSB requires.
Discussion: My (steveg's) reading of the LSB (section X) is that apps
shouldn't require a specific ID, but it also reserves 0-99 for static
allocation by the system (distribution?), so they don't seem to be
absolutely forbidden. I don't think we can forbid them absolutely so
long as accommodate non-free programs. We might want to make it clearer
in policy that they're strongly discouraged. Or this might not be a
matter for policy at all. This probably should be re-submitted with a
specific diff for policy and an example of how much it work it
actually is.
Action: close
========
Bug #43724: experimental patch for very much faster dpkg -R
Summary: A patch for dpkg to speed up disk based installs requires
that version numbers be distinct, even ignoring epoch (e.g. 1:1.0-1
and 1.0-1 were not allowed.)
Discussion: Wichert says this patch never made into dpkg, and given the
current state of apt and dpkg development, won't be used.
Action: close
========
Bug #43757: My emacs can't find some info files
Summary: Submitter pointed out that emacs19 couldn't find info files
installed in /usr/share/info when the dir file was in
/usr/info. Responders seemed to agree that this was bug in emacs19
rather than policy, and there was some discussion about the /usr/info
to /usr/share/info transition.
Discussion: Emacs19 isn't even in unstable, and emacs20 seems to
deal with this fine, so it seems like a non-issue at this point.
Action: close
========
Bug #43928: libc and kernel source policy
Summary: Arguments for and against including a specific set of kernel
headers in the libc source vs. depending on a specific kernel-header
package vs. just taking whatever's installed. Consensus seemed to be
that current situation is "best" (most stable, fewest luser bug
reports) and those that actually need newer kernel headers are also
those who are most capable of understanding the right way to get them.
Discussion: I'm not sure why this is still open -- consensus was
clearly for status quo.
Action: close
========
Bug #51842: close advertising hole in the DFSG
Summary: Are DFSG free licenses allowed to restrict or require
advertising content when distributed? (e.g. old style BSD)
Discussion: This is clearly not a debian-policy issue, but something
that requires modifying/clarifying the DFSG.
Action: close
========
Bug #54968: Lintian, archive maintenance and and policy
Summary: Proposal that since (a) dinstall was auto-rejecting packages
with lintian errors, there (b) should be a way for the maintainer to
override. Responders pointed out that (a) wasn't true and that (b)
already existed, although it was perhaps under-documented. Lot's of
followups related to specific situations.
Discussion: Since the premises of the proposal wasn't true, and the
solution already exists, this proposal seems irrelevant.
Action: close
--
Steve Greenland <stevegr@debian.org>
(Please do not CC me on mail sent to this list; I subscribe to and read
every list I post to.)
Attachment:
pgp3_1h1nHwqy.pgp
Description: PGP signature