libXp -- was there a better way?
Hello
I am running Buster on c2009 amd64 hardware -- one of the earliest Intel
Core i7s. This was a clean install of Buster done a little over a year
ago. Previously I had run many older flavours of Debian on this hardware
over the years.
I occasionally use a specialist piece of software called xephem, which
is old but doesn't to my knowledge have a newer replacement that's 1% as
good. I tried to fire it up the other night for the first time since I
installed buster. It refused to run because libXp.so.6 was missing. A
bit of googling showed me that this is an old, deprecated library for
printing in X. I couldn't run the execuable of xephem I had previously
built and I couldn't build the latest version because of its expectation
to find the include <extensions/Print.h> which is provided by the same
library... ("latest" version isn't very new...)
libXp.so.6 was last in Debian in Jessie, in package libxp6. Looking at
the dependencies of libxp6 in Jessie, they were all installed on my
system (obviously newer versions) except multiarch-support. So I
downloaded the package from Jessie and used gdebi to install it on my
system. This worked, and now xephem runs.
To avoid trouble when I next upgrade I propose from here to create a
dummy package for xephem using equivs to register the dependency on
libxp6, and then mark libxp6 as automatically installed, so the package
manager in a future upgrade can figure out it can remove xephem's dummy
package and thereby get rid of libxp6 if it causes conflicts. I have no
idea if xephem will now be able to print, but I don't care as I don't
want to use its printing functionality, I only did any of this because
the missing library was preventing it from starting.
My question is, was there a better way to resolve this dependency? And,
in a Buster system which has been installed not upgraded, am I in danger
of creating trouble for myself by having this old package on my system?
Thanks
Mark
Reply to: