a nitpicky reading of policy
I read through the policy document today, trying to nitpick and find things
that have changed in current practice. Here's what I found:
* The policy manual uses the term "section" to refer to main, non-us,
non-free, and contrib. This overloads the term since we typically call
games, libs, docs, etc, sections. Instead, it calls those things
subsections. It also uses the term inconsitently:
The packages in all the sections (_main_, _contrib_, _non-US/main_,
_non-free_, _non-US/contrib_, and _non-US/non-free_) are grouped
further into _subsections_ to simplify handling.
^^^^^^^^^^^
The section for each package is specified in the package's _control
^^^^^^^
record_. However, the maintainer of the Debian archive may override
this selection to assure the consistency of the Debian distribution.
^^^^^^^^^
Please check the current Debian distribution to see which sections are
^^^^^^^^
available.
...
The packages included in the `base' section have a special function.
^^^^^^^
I think this deserves to be cleaned up, but I don't really know what to
call main, contrib, and non-free. Distributions, maybe?
* The definition of the standard priority says it includes:
and a reasonable
subset of TeX and LaTeX (if this is possible without X).
Which implies that X is not standard. However, xlib6g and xfree86-common
are standard. I think the text in the parens should be removed.
* "Every package must have exactly one maintainer at a time." This statement
is violated by so many packages (including dpkg) that it should be removed.
* This seems self-contradictory. Are you supposed to remove the created
directories or not?
However, the package should create empty directories below
`/usr/local' so that the system administrator knows where to place
site-specific files. These directories should be removed on package
removal if they are empty.
Note, that this applies only to directories _below_ `/usr/local', not
_in_ `/usr/local'. The directory `/usr/local' itself may only contain
the sub-directories listed in FHS, section 4.6. However, you may
create directories below them as you wish. You may not remove any of
the directories listed in 4.6, even if you created them.
* Lines 1076 and 1177 of policy.text.gz should be indented by another tab.
(This problem is not unique to the text version.)
* "Please look very careful at the details." s/careful/carefully/
* "file ftp.debian.org in /debian/doc/package-developer/menu-policy.txt"
Actually, the file ends in .gz.
* "The Debian `menu' packages provides" There is only one menu package, so
s/packages/package/
* "ftp.debian.org in /debian/doc/package-developer/mime_policy.txt"
Actually, the file name is mime_policy.text.gz
* "Any scripts which create files in world-writable directories (e.g., in
`/tmp') have to use a mechanism which will fail if a file with the
same name already exists." I can write code that complies with this and is
still a serious security problem -- the problem is that this sentance
encourages the naive to write something like:
if [ ! -e /tmp/foo ]; then
echo "goodbye, /etc/passwd" >/tmp/foo
fi
Which is vunerable to a race. I think it's be better to require that
it use a "mechanism which will atomically fail ..."
* "If your packages creates or uses configuration files outside of
`/etc', and it is not feasible to modify the package to use the
`/etc', you should still put the files in /etc' and create symbolic
links to those files from the location that the package requires."
"Use the `/etc'" sounds a little weird to me, perhaps s/the//
* "must not overwrite or otherwise mangle the user's
configuration without asking, must not ask unnecessary questions
(particularly during upgrades), and otherwise be good citizens."
Just to remove the tiny shred of ambiguity from this sentance, I'd say
change the end to "and must otherwise be ..."
* "Do not arrange that the system administrator can only reconfigure the
package to correspond to their local security policy by changing the
permissions on a binary. Ordinary files installed by `dpkg' (as opposed to
conffiles and other similar objects) have their permissions reset to the
distributed permissions when the package is reinstalled. Instead you should
consider (for example) creating a group for people allowed to use the
program(s) and making any setuid executables executable only by that group."
This paragraph seems to be unaware of suidregister. Perhaps it should
mention it as an alternative.
* "where <arch>' is one of the following: i386, alpha, arm, m68k,
powerpc, sparc and <os>' is one of: linux, gnu. Use of _gnu_ in this
string is reserved for the GNU/Hurd operating system. ."
Notice the trailing dot.
--
see shy jo
Reply to: