On Sun, Jun 19, 2005 at 05:15:39PM +0200, Andreas Barth wrote:
> 1. DFSG-freeness
> Code {+and Documentation+} in main and contrib must meet the DFSG,
> both in .debs and in the source (including the .orig.tar.gz).
Clearer to say "all content" instead.
> 4. Autobuilding
>
> [...]
> debian/rules must include the targets: clean, binary, binary-arch,
> binary-indep and build; and these targets cannot require any
> interaction with the user. The build target must not do anything that
> requires root privileges. {+None of these targets may change the
> packages build-dependencies or the changelog.+}
"These targets must not change the package's build-dependencies or the
changelog"? (apostrophe definitely needs to be added, at least)
> 5. General
>
> [...]
>
> (l) Mail
>
> [...]
>
> MTAs must provide /usr/sbin/sendmail, and a symlink to that
> program as /usr/lib/sendmail. {+/usr/sbin/sendmail must provide
> the -bs switch, unless the package conflicts with LSB.+}
The /usr/sbin/sendmail command must implement all command-line options
specified by the LSB with the exception of the -bs switch. MTAs which do
not provide the -bs switch must Conflict: with the lsb package.
> [...]
>
> (p) Linux Standard Base
>
> Packages must not conflict with requirements of the LSB,
> v1.3. (eg, if you provide a library specified in the LSB, you
> must be compatible with the LSB specification of that library)
>
> Basically, you should be LSB compatible. You can expect a bug
> report to be filed if you're not, and if you don't know how to
> fix the problem, you should email debian-lsb@lists.debian.org
> for assistance.
>
> {+[Expect that the LSB Version will be bumped to 3 during etch
> development.]+}
Perhaps we should be making this decision so that this isn't left as a
footnote. Maintainers need to know which version they're targetting, since
they're not compatible. For one thing, AIUI we're not going to be able to
provide a libstdc++ library for any LSB version other than LSB3 without some
additional work.
> (q) Python
>
> Packages providing python modules must comply with the python
> policy (naming scheme and dependencies). See
> http://people.debian.org/~joss/python/python-policy-draft.txt
>
> {+[Expect that the python policy and implementation will change
> during the etch development cycle]+}
Again, I'm not sure why we want to write that in the rc checklist.
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature