Dear G, Sorry for keeping you waiting. Packaging another library (libipset) just takes some time.
On Wed, Jun 1, 2016 at 10:40 PM, Gianfranco Costamagna < locutusofb...@debian.org> wrote: > Hi again, > >>It's false positive. > > ack Thanks! >>> Replaces: shadowsocks (<< 1.5.3-2) >>> Breaks: shadowsocks (<< 1.5.3-2) >> >>Thanks to co-maintainer Boyuan, below comments are from him. >> >>==== >>Upstream used to use the package name **`shadowsocks'** long long ago, >>and the name was changed into `shadowsocks-libev' [0] since version >>1.5.3-2 in order to prevent the naming conflict with python version of >>shadowsocks [1]. >> >>Upstream has been providing debian directory for a really long time >>(earlier than v1.3), so someone may be installing the *libev* version >>of debian package called `shadowsocks'. You may notice that for python >>version of shadowsocks, the **initial** release was 2.1.0 [2] and will >>not bother with shadowsocks << 1.5.3-2. . So setting Replaces / >>Breaks: shadowsocks << 1.5.3-2 should be the best way to deal with >>those two problems. >> >>[0] https://github.com/shadowsocks/shadowsocks-libev/blob/master/Changes#L205 >>[1] https://packages.debian.org/sid/shadowsocks >>[2] http://metadata.ftp-master.debian.org/changelogs//main/s/shadowsocks/shadowsocks_2.1.0-1_changelog >>==== > > > does this mean that actually they aren't installable together? > (note: I already know the answer :p ) Technically yes, but since it's a quite old version, I think nobody would do it. And currently "shadowsocks" is a python program in Debian archive, we don't recommend to install the old C-written shadowsocks. >>I didn't package ipset because: >>- Almost dead upstream. There're a few questions and pull request is >>pending on github for years. >>- I cannot compile by the steps described in upstream's INSTALL file. >>It failed on linking. >>- Current embedded library just works, because shadowsocks-libev's >>upstream has modified this library to improve compatibility on >>multi-platform. >>==== > > > do you have logs for the failures? doesn't upstream have possibility > to switch to a more maintained library? > > I tried to find ipset on github, and I think I found the right one. > > I fixed the link failure I guess you were referring to and opened an upstream > pull request. > > https://github.com/redjack/ipset/pull/40 > > I still prefer it to be packaged, and maybe you doing a diff between the two and patch > with Debian patches the differences. > This way you can send patches upstream, and one day if nobody answers to them, > maybe just fork, apply all of them, and release a new version. Thanks for your patch! It really worked since that. So I packaged it and filed ITP#827080 / RFS#827082. Hope you can also sponsor it. > Otherwise you will have the embedded-code-copies issue, and maybe prevent other people > from using it. >>> 5) >>> sed -i "/dependency_libs/ s/'.*'/''/" `find . -name '*.la'` >> >>It's workaround for lintian: >>https://lintian.debian.org/tags/non-empty-dependency_libs-in-la-file.html > > > I think the best fix is to remove the .la files > override_dh_auto_install > find blah -delete "*.la" > dh_auto_install > > might work :) Thanks for your detailed tips! I just remove the text after "-delete", others are just as what you said. Works fantastic! >>It's runtime config file, which will be installed to: etc/shadowsocks-libev > > not sure about hardcoding passwords that way... maybe generate them at install > time with apg or similar? > (postinst or similar) > > I don't want all the userbase to have the same tool with the same default password. Done. Add postinst script to handle this. Hope you cannot find a nitpick this time :-P Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 17B3ACB1
