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 [email protected] [email protected] [email protected] PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
