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

Re: Bug#646069: Debian and AutoMake



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


Reply to: