On Wed, Apr 06, 2016 at 01:39:07PM +0000, Gianfranco Costamagna wrote: > control: owner -1 ! > control: tags -1 moreinfo > > Hi Peter, > changes are huge! Yes, they are... I've put off updating dante from 1.2.x to 1.4.x for a couple of years :( > lets see: > > some copyrights are missing > # Copyright (C) 1994 X Consortium > Radical Eye Software > > Internet Software Consortium. Argh, I'll look at that, thanks. > licensecheck * -r > > reports lots of missing licenses (BSD-4 as example) Right, I'll look at that, too. > while your "other" license might be considered a > > BSD-3-clause-like True, I'll change it. > please consider using the same license for Debian and Upstream, to ease patch forwarding > without having to relicense Hm, yes, this is not such a bad idea (and I do it for all of my packages), although in this case it might mean contacting the people who maintained dante before me in Debian and asking them about relicensing their patches. I'll consider this. > please don't drop the NMU from <doko> > "dante (1.1.19.dfsg-3.1) unstable; urgency=medium" Arrrrgh! I thought I'd imported that when I reimported all of dante's upstream source and Debian packaging into a new, full-source repository... grrr! Of course I'll fix that, thanks! > +Standards-Version: 3.9.8 <-- we are on 3.9.7 now Eh, well, not as of today :) > +Package: dante-client <-- section oldlibs now? 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 :( So, the thing is, now it's in an arch:all package; it examines the program that the user asked it to run, then chooses the /usr/lib/*/dante-client/libdsocksd.so file for the correct architecture (thus the multiarch-find-lib tool), puts it into LD_PRELOAD, then runs the program that the user asked it to run. The thing is, now you can have several dante-client-lib (arch-specific) packages containing the various /usr/lib/*/dante-client/libdsocksd.so helpers, and one socksify to bind them, thus allowing you to run e.g. both amd64 and i386 binaries through SOCKS proxies. This was impossible until now, and I have a couple of bug reports in the BTS to prove it :) So, yeah, people would still install either dante-server (for the proxy itself) or dante-client (for running programs through the proxy) or both. > changing symbols, doesn't break ABI? I think you have to bump SONAME Hm. This is a weird case; practically nothing in the archive depends on dante's client library, and it has been severely outdated for years now. Moreover, the symbols themselves are just do-nothing internal wrappers around libc's symbols, so even if somebody compiled something against libsocksd.so.0, the linker would *still* find all the symbols - in libc itself! :) The pedantic thing to do would be to bump the SONAME, but in practice nothing would ever feel the change - the "dropped" symbols would be resolved in 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. > multiarch-find-lib <-- why? See the above explanation about socksify in dante-client. The thing is, dante is a special piece of software that needs to know which libraries match an executable's ABI in much the same way as the Linux runtime loader does, but I couldn't find an interface to ask for that, so I wrote the tool to do it. > I prefer autoreconf instead of autotools-dev Yep, that's part of the reason I updated to debhelper 10; please see the changelog of debhelper-9.20160402 and 9.20160403 :) Still, there are some packages and weird architectures that need autotools-dev *in addition to* autoreconf; see e.g. https://bugs.debian.org/766734 in mbuffer. > compat level 10? wow :) Yep, not experimental any longer since 9.20160402, but better to use 9.20160403. > dh_install > I prefer install instead of cp :) 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. Otherwise I do agree with you in principle, I always advocate for the use of install with explicitly specified -o, -g, and -m, but in this particular case the files already have the correct attributes, so install commands (or even macros) would only complicate and obscure the purpose. > as a side note: I don't understand why you overcomplicate stuff. > the upstream build system should know where to install stuff (multiarch and conf files) > if not, what about patching it? 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 :) 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. > the other stuff LGTM, please try to address at least some of the above points, and I'll sponsor it 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. > please also consider merging the Ubuntu delta > https://launchpad.net/ubuntu/+source/dante/1.1.19.dfsg-3.1ubuntu1 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. G'luck, Peter -- 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
Attachment:
signature.asc
Description: PGP signature