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