Bug#646356: Fwd: Bug#646069: Debian and AutoMake

[Scott Howard]

Below is a comment from Philip


---------- Forwarded message ----------
From: Philip Ashmore <contact at philipashmore.com>
Date: Sun, Oct 23, 2011 at 12:17 PM
Subject: Re: Bug#646069: Debian and AutoMake
To: debian-devel <debian-devel at lists.debian.org>
Cc: Scott Howard <showard314 at 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