Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Using (old) Ubuntu libjpeg packages to allow some older programs still running on recent debian

100 views
Skip to first unread message

Maris, Rob

unread,
Aug 3, 2022, 7:40:05 AM8/3/22
to
The subject is considered as dealing with Utnubu - but according to the appropriate wiki page, this team has stopped to exist "many years ago". Therefore I write in this list.

Next I describe a case which make me think that Debian has less a focus on keeping less recent lib packages part of more recent debian versions. More important: two other packages part of both Ubuntu and Debian prove to result in removal of old programs on Debian, but not on Ubuntu!

Regarding better backward compatibility: libjpeg8 and libpeg62 exists both in Ubuntu (till today); but in Debian only the latter. In my case I had to install libjpeg8 from ubuntu on my debian-based system (as well as gstreamer0.10-plugins-good)

Yesterday, I experienced that installation of jhead on a Debian based-machine results in installing just a slightly different version of libjpeg-turbo-progs and libturbojpeg0 (compared to Ubuntu). In my case this would also incur removals of libjpeg8 and libjpeg-turbo8 & gstreamer0.10-plugins-good, which I "imported" some time ago from Ubuntu packages in order to continue the use of old application stuff. Doing the same (installing jhead on an ubuntu-based machine) does not affect anything. But: when apt install jhead is executed on Debian 11 *after* the next two Ubuntu packages are installed via dpkg, no complaints are made.

To be precise:
Debian | Ubuntu
libjpeg-turbo-progs 1:2.0.6-4 | libjpeg-turbo-progs 2.0.6-0ubuntu2
libturbojpeg0 1:2.0.6-4 | libturbojpeg 2.0.6-0ubuntu2

Please take notice of the extra 0-suffix in the libturbojpeg name from the Debian 11 repository. My actual question: what does the Debian-version of these two libs make incompatible with libjpeg8 and three other libs - all "imported" from Ubuntu?

A practical problem arises with these two libs. When apt upgrade (or e.g. use KDE discovery) is being executed, the system will try to "upgrade" these two packages to the original Debian version. And that's annoying because I must decline those upgrades in order to prevent the automatic removal of four lib packages and one (old) application...

Regards,
Rob

Dan Ritter

unread,
Aug 3, 2022, 8:40:05 AM8/3/22
to
Maris, Rob wrote:
> Next I describe a case which make me think that Debian has less a focus on keeping less recent lib packages part of more recent debian versions. More important: two other packages part of both Ubuntu and Debian prove to result in removal of old programs on Debian, but not on Ubuntu!
>
> Regarding better backward compatibility: libjpeg8 and libpeg62 exists both in Ubuntu (till today); but in Debian only the latter. In my case I had to install libjpeg8 from ubuntu on my debian-based system (as well as gstreamer0.10-plugins-good)

You have created a FrankenDebian.

If you need to keep an old application running and you can't
fix it to work with new libraries, you have entered the world of
dependency management. Some general solutions:

- run an old version of the operating system in a VM. This is
the most reliable method.

- use a container to supply exactly the versions of the
libraries that the old application needs. This may eventually
stop working when kernels or libc or similar basic
infrastructure gets upgraded, but is pretty good otherwise

-dsr-

Ángel

unread,
Aug 9, 2022, 7:50:05 PM8/9/22
to
Rob, you haven't mentioned which old program is keeping you from
updating.
In addition to the options that Dan said (running the program in a VM
or a container):

You may be able to rebuild the program with the newer libraries. Most
likely, a simple rebuild like this will work fne. This would be the
best solution as it would let you use the old program with the old
newer libraries.

It is sometimes possible to manually force an old program to use newer
libraries. If you are lucky it will be compatible, but it could also
break horribily.

A "modern" way of running the old program with its old requisites would
be to do so as a snap / flatpack. Although you would probably need to
build it, as it's unlikely to be available.

Regards
0 new messages