[Pkg-silc-devel] updating, cleaning debian silc packages; policy compliance 3.8.0

[Micah Anderson]

Hey there,
* Daniel Kahn Gillmor <dkg at fifthhorseman.net> [2008-09-29 07:02-0400]:
> Hey folks--
> 
> I just did a trivial little cleanup of the silc packages in svn, based
> on some of lintian's complaints:
> 
>
>http://lintian.debian.org/full/pkg-silc-devel@lists.alioth.debian.org.html

Thanks for cleaning those up!

> One of the complaints that i didn't fix is that we've got a 26MB chunk
> of data in /usr/share/doc/libsilc-1.1-2-dev in our libsilc-1.1-2-dev,
> which is ostensibly architecture-dependent.  This is massive chunk of
> data is duplicated across every architecture, which seems silly.  If
> we want to ship this documentation, it seems to me like we should
> break out an architecture-independent -doc package from the same
> source.

I agree, this would be better to split out into a -doc package.

> One concern in svn (not yet published) is that the proposed policy
> change to 3.8.0 in the silc-client source (1.1.4-2) is probably not
> acceptable without significant changes to the packaging.

I'm a bit confused by this paragraph, but I think I am able to parse out
what you mean. One point is that the policy change in 3.8.0 is not
proposed, but rather accepted.

> In particular, the new "convenience copies" section [0] of
> debian-policy seems to be violated by the silc-client sources, which
> contains convenience copies of source from irssi and source from
> silc-toolkit.  The silc and irssi-plugin-silc binary packages both
> appear to run afoul of this clause.

They do indeed.

> This looks to me like a policy violation, which would be potentially
> RC, unfortunately.  What do others think?  How should we address this?

I was part of the discussion to add this criteria to the policy[0], as
this has been a long-standing problem in the testing-security team (also
in the stable security team) with regards to embedded code copies. There
are a lot of packages in Debian that include source code from external
libraries, for example poppler is included in xpdf, kpdf, etc. Dealing
with vulnerabilities in packages that are embedded in other packages is
annoying and difficult to keep track of (we actually do keep a list[1]).

This policy bug was filed to try and push people to move away from
embedding copies of code in packages, and instead link against packages
that already exist in the archive. Its actually already almost an
automatic NEW reject by the FTP masters.

The point of this policy bug was not to forbid the practice, but to
strongly discourage it, and this is is why this is a "should not" rather
than a "must not". With that said, I think that we should try to
overhaul the package, but this would not actually be RC.

> Since 3.8.0 is not a requirement for lenny, the simplest way to
> resolve this would be to not bump the policy version to 3.8.0 until
> lenny is out the door, and try to do a packaging overhaul after that.

I think thats a fine approach actually.

Micah


0. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392362
1. http://svn.debian.org/wsvn/secure-testing/data/embedded-code-copies?op=file&rev=0&sc=0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-silc-devel/attachments/20080930/9fce35ba/attachment.pgp