Re: a few questions on ITP shadowsocks-libev before formal RFS
* Roger Shimizu <rogershimizu@gmail.com>, 2016-05-18, 02:14:
I'm doing ITP packaging on shadowsocks-libev. I have a few questions in
detail.
I have set up a git repo on github: https://github.com/rogers0/shadowsocks-libev
My current changes are pushed to branch: RFC
Package builds fine with command: gbp buildpackage -us -uc
--git-ignore-branch
Some questions/issues that I'm not sure:
- Upstream maintained debian/ folder long before, I'm going to keep the
original debian/changelog. So I should also keep the upstream as
maintainer, and add myself as the uploader?
It doesn't matter who maintained the package in the package. What
matters is who is going to maintain it now for Debian. Did you ask
upstream to co-maintain it with you? You certainly shouldn't put anyone
to Maintainer/Uploaders without their consent.
- The package is mainly GPLv3, but it links to OpenSSL library, is that
OK?
GPL+OpenSSL is no-no.
README says that mbedtls, which is GPL-compatible, can be used as an
alternative to OpenSSL, so you should try it.
- Upstream repo includes library source code of libev, libsodium,
libudns. Is it OK to keep as it is, or have to remove and make another
source tarball?
As long as they are DFSG-free, you can keep them in the source package.
Just make sure they are not used at build time. This is best achieved by
"rm -rf"ing them early in the build process. (If you're using dh, then
beginning of override_dh_auto_build is probably the best place.)
- The answer of above question may affect: whether I should remove
copyright of library libev, libsodium, libudns from debian/copyright?
If you keep them in .orig.tar, then you must also keep them in
debian/copyright.
If you remove them from .orig.tar, then remove them from
debian/copyright too.
- Is it needed to add "dh_autoreconf" in debian/rules?
It's not required by policy, but many sponsors will (rightfully!) insist
to regenerate autotools stuff from source.
- I have no idea on the following lintian error, because
postrm/postinst scripts are generated by dh
====
E: shadowsocks-libev: postrm-contains-additional-updaterc.d-calls etc/init.d/shadowsocks-libev-local
This seems to be caused by passing --no-start to dh_installinit:
dh_installinit --no-start --name=shadowsocks-libev-server@
dh_installinit --no-start --name=shadowsocks-libev-tunnel@
dh_installinit --no-start --name=shadowsocks-libev-redir@
dh_installinit --no-start --name=shadowsocks-libev-local@
My initsystem-fu is too weak to tell whether it's a d/rules bug,
debhelper bug, or Lintian bug, or just something that should be
overridden.
--
Jakub Wilk
Reply to: