Bug#820196: RFS: dante/1.4.1+dfsg-1 -- new upstream version, packaging updates
damn, I saw debian-policy in deferred/10 or whatever, I wasn't aware it got accepted today :)
thanks!
>No, this package is still alive and well, it contains the "socksify" tool
>that preloads the Dante libraries necessary to run a network program using
>a SOCKS proxy - pretty much the main reason anyone would ever install dante
>at all :) The thing is, now this shell script is in an arch-all package...
>wait, what?! It isn't, is it... I forgot to change it to arch:all :(
ok, I hope the upgrade path will be ok, I saw now dante-client depends on dante-client-lib
so we should be safe (I'll run piuparts to be sure)
>the next library in the chain. Still, I could bump the SONAME and maintain it
>as a Debian-specific one for some time, I guess, if you insist.
no please :)
>Yep, not experimental any longer since 9.20160402, but better to use 9.20160403.
just note that backports will be impossible for some time, until it goes in bpo
(please read -devel mail list)
>
>Hm, in this case it does not really matter, since cp would preserve the attributes
>of the files that were *already* installed by the upstream's build system, so
>I saw no reason to change the previous maintainers' code. To be honest, I *am*
>thinking about doing something interesting with executable debian/*.install files,
>but this is only a handful of files for each package, the rest are handled perfectly
>well by the static debian/*.install files.
as you prefer!
>Hm, it's a bit weird. The thing is, the Debian package of dante renames some of
>the binaries, executables, and config files, so patching it would not be enough -
>we would still have to either copy, link, or rename some files, either in the source
>or in the installation process. It would be difficult to patch the upstream build
>system to take the socks.conf.5 file and install it as dante.conf.5 - I don't think
>autoconf/automake even has this capability - so we'd have to copy/link socks.conf.5
>to dante.conf.5 in the source and then patch the Makefile to install dante.conf.5
>instead of socks.conf.5... which is one step *more* than the copying done now :)
ok
>About the multiarch thing: this is not what it looks like :) The upstream build system
>already knows how to install the libdsocksd.so file into the correct /usr/lib/*/
>multiarch directory; what it does *not* know how to do is install it into a *subdirectory*
>of /usr/lib/*/. This particular file is not a real library, so it doesn't have (or need)
>a proper SONAME, so it cannot live in /usr/lib/*/, it must live in a subdirectory,
>just like the NSS loadable modules /usr/lib/*/nss/*.so or the Perl XS modules in
>/usr/lib/*/perl/5.x/auto/. Well, it's not easy to get automake to install a library
>into a subdirectory (while installing all the other libraries in the same project into
>the actual library directory); it's much easier to do it this way.
I don't know the stuff behind this, but isn't an rpath an acceptable solution then?
>Thanks for taking the time to look at it! I'll fix the copyright and>license stuff, add back the NMU, and switch dante-client to arch-all, and then
>I'll get back to you.
thanks, I already trust your work on other packages I sponsored to you, so
feel free to drop what you don't agree.
>Thanks for pointing that out, but I've already looked at it and all of it is
>either handled in the new upstream version (hence Closes: #731178), or
>handled by the new multiarch-aware dante-client.
thanks for double checking, I'll wait for the revised upload then :)
cheers,
Gianfranco
--
Peter Pentchev roam@ringlet.net roam@FreeBSD.org pp@storpool.com
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Reply to: