Re: Is Dermot Bradley Dead?

[Rob Tillotson <robt@debian.org>]

Chris Waters <xtifr@dsp.net> writes:
> Just curious.  The pilot-link package in potato seems to have been
> broken to the point of unusability for some time.

Hmm, what's "broken to the point of unusability"?  It seems to work
just fine for me, although all I ever really use from it is a few of
the most useful utilities.  I don't see any open bug reports that
look particularly bad (except perhaps the register_frame_info thing,
which I don't seem to have a problem with), so perhaps you should
report whatever problems you are having as a bug...

> I would have some questions for those who have been using the Debian
> pilot tools a little longer than I have though, like, why was the
> library split out of pilot-link into a separate package?

>From the Policy Manual, section 4.3:

  "If your package has some run-time support programs which use the
  shared library you must _not_ put them in the shared library
  package.  If you do that then you won't be able to install several
  versions of the shared library without getting filename
  clashes. [...]"

Avoiding filename clashes is a practical reason to split libraries
into separate packages, but there is a very good operational reason to
do it as well: avoiding the installation of unnecessary software, and
avoiding transitive dependencies.

For example, consider "pyrite", of which I am both maintainer and
upstream author.  Pyrite uses libpisock3 for communication with the
handheld, but it quite deliberately does NOT rely on the pilot-link
binaries.  In fact, Pyrite is intended to eventually be a complete
replacement for pilot-link's "userspace", in almost pure Python.  The
fact that it uses libpisock3 at all is a concession to practicality;
otherwise, it stands alone.  In the future, pyrite's dependence on
libpisock3 won't even be a Depends:, but a Recommends: or even just a
Suggests:.  Why force it to pull in a bunch of stuff it doesn't
actually need?

> And would newer versions of the pilot-link package really be
> compatible with libraries from older versions?

Probably not, but since they're built from the same source it doesn't
matter... when you rebuild the source, you'll get a set of packages
that correspond to one another.

Enjoy,
--Rob

-- 
Rob Tillotson  N9MTB