[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]



Hi again,



>It's false positive.


ack

>> 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 )

>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.


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 :)
>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.

>>Hope you feel the updated package more comfortable.
>Thanks again!


I like it, just I like to nitpick/bother too ;)


thanks!

G.


Reply to: