Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228151 > unrolled thread

libXp -- was there a better way?

Back to article view | Back to linux.debian.user

Contents

  libXp -- was there a better way? Mark Fletcher <mark27q1@gmail.com> - 2020-10-24 01:00 +0200
    Re: libXp -- was there a better way? Sven Joachim <svenjoac@gmx.de> - 2020-10-24 08:50 +0200

#228151 — 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

[toc] | [next] | [standalone]

#228153

On 2020-10-23 23:53 +0100, Mark Fletcher wrote:

> 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.

That is true, it is a client library for a server (xprint) which had
been removed from Debian a few years earlier.

> 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...)

From 2015, I guess the xephem authors have stopped its development.

> 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.

Sounds like a good plan to me.

> 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.

I guess it won't be able to print because of the missing server, but
maybe I am wrong here.

> 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?

Quite unlikely, the only problem is the missing security support for
this library and the software using it (i.e., xephem).

Cheers,
       Sven

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web