Below is a comment from Philip
---------- Forwarded message ---------- From: Philip Ashmore <cont...@philipashmore.com> Date: Sun, Oct 23, 2011 at 12:17 PM Subject: Re: Bug#646069: Debian and AutoMake To: debian-devel <debian-de...@lists.debian.org> Cc: Scott Howard <showard...@gmail.com> Hi there. This email isn't a criticism of rxtx - thanks Scott for accepting my patch. It's more of a starting point for issues with development on Debian and other distributions - see the last comment. On 23/10/11 15:08, Scott Howard wrote: > > clone 646069 -1 > retitle -1 rxtx: make -dbg package for rxtx > retitle 646069 rxtx: fails when "java.ext.dirs" system property > contains more than one directory rxtx doesn't fail, it just fails to read any gnu.io.rxtx.properties file that may exist in one of these directories because the filename is constructed from the directory names joined with ":". I created a gnu.io.rxtx.properties file in one of the directories but I don't know what would happen (Java-wise) if there were more than one of these files - I haven't tested it. It will work without finding any gnu.io.rxtx.properties file. > > severity -1 wishlist > thanks > > Thanks for the patch, great work. > > Separated this into two bugs > > 1) I'll apply the patch and forward it upstream. RXTX really isn't > maintained much anymore upstream, but I'll at least share it on the > mailing list. > 2) We'll build with make -DDEBUG_VERBOSE and make a -dbg package for gdb. A "foo-dbg" package is one with debugging symbols for package "foo". Maybe "rxtx-verbose" would be a better name, with rxtx <- conflicts -> rxtx-verbose as an install option. > > As for the make uninstall, autotools does a poor job with uninstall > targets [1] and upstream has a custom install target that just puts > the RXTXcomm.jar into the same directory as the jvm and libtool > install the native libraries. The Debian source package really isn't > intended to be used to install outside of the debian packaging system. That's a shame if it's the case in general. I certainly wouldn't have considered using dpkg-buildpackage given the turnaround I wanted with the source code changes. fakeroot debian/rules binary didn't work either. I've got some packages in SourceForge. You can get them via http://sourceforge.net/users/philipashmore You can build Debian/Ubuntu packages with make debian You can install/uninstall them with make install make uninstall using the makefile in the package root that wraps automake. You will need to use "sudo" if you want to install them in a system directory, like /usr or /usr/local. If you've git-cloned a package repository you can also do things like make git branch=a.b.c distcheck make git tag=a.b.c release debian The "tag" variant is for branches you tag locally. If you want to build a package in a sandbox along with all its dependent v3c packages, you git clone the v3c packages into some directory writeable by you, then you can use v3c's "v3c-tryout" script v3c-tryout <pkg-name-version> <sandbox-dir>, as in ./v3c-tryout v3c-dcom-0.3.2-01 tryout-v3c-dcom and it will 1. git checkout the respective versions of the dependent packages as required by the version of the package you specified, into the sandbox dir. 2. build and install them to the sandbox dir in order. 3. create shell scripts to set up a (b/d)ash session inside the sandbox, to test the packages or run "make check", mess with the sources, uninstall... > > to uninstall, just delete the .jar and > glibtool --mode=uninstall $(RM) list_of_targetlib > > Cheers, > Scott > > > [1] http://sourceware.org/autobook/autobook/autobook_109.html I'd really like to see something like this adapted by Debian and other distributions to save developers from reinventing the wheel or discovering that the package doesn't adhere to published documentation. What do you think? Philip __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.
