[Discussion] correspondence among deb repositories

[yvs222]

Hi everyone,

I have a couple records to PPA in apt sources that used on Debian bookworm.
Using them I have to find out some correspondence (usually once) among Ubuntu and Debian name distros for a particular package to get its working version.
In result of manual testing them out there could be jammy/nobble/etc package versions that work with bookworm system.
If that's possible, is there a way (or a tool) to find out these correspondences automatically?

[bbbhltz]

Jammy Jellyfish, Kinetic Kudu and Lunar Lobster are built on Bookworm/Sid

https://en.wikipedia.org/wiki/Ubuntu_ve ... n_timeline

Mantic Minotaur and Noble Numbat are based on Trixie/Sid

[yvs222]

Jammy Jellyfish, Kinetic Kudu and Lunar Lobster are built on Bookworm/Sid
https://en.wikipedia.org/wiki/Ubuntu_ve ... n_timeline
Mantic Minotaur and Noble Numbat are based on Trixie/Sid

Thanks, but it's too general, for example some packages built for Noble are used in Bookworm and so on.
Packages with binaries built from C could be checked out the presence of corresponding libs from ldd output, in practice I just look through names from newer down to older ones with which it works.
Another considered option is OBS build debs already for Debian, but its rpm based manifest baffles a bit.

[Aki]

Hello,

I have a couple records to PPA in apt sources that used on Debian bookworm.
Using them I have to find out some correspondence (usually once) among Ubuntu and Debian name distros for a particular package to get its working version.
[..]
If that's possible, is there a way (or a tool) to find out these correspondences automatically?

You are walking in a mine field:

• Advice For New Users On Not Breaking Their Debian System

I suspect you are not a "new user", so please excuse me in advance, but for the general user, looking for a match between binary packages and libraries from different distributions (even if they are derived from Debian) in order to drop them into the same installation will sooner or later cause problems (unresolved dependencies, program malfunctions due to library incompatibilities).

In general, it is a practice to avoid unless you are aware of the risks and accept the possibility of reinstalling part or all of your system.

[yvs222]

> for the general user, looking for a match between binary packages and libraries from different distributions (even if they are derived from Debian) in order to drop them into the same installation will sooner or later cause problems (unresolved dependencies, program malfunctions due to library incompatibilities).

That's for sure, but there's two options that I have been using:
- git clone an original source, build it with (dpkg-buildpackage for example) and install it (pros: it corresponds to installed system; cons: need to install -dev packages, building system, etc. at every need)
- use corresponded auto-built deb from some build system (launchpad or obs for example) by adding repository to apt sources (pros: there's ready to use deb; cons: launchpad - a distinct derivative, obs - (yet) cannot figure out all building options there)
- maybe there's some better options that I missed at this point

[Aki]

Hello,

That's for sure, but there's two options that I have been using:
- git clone an original source, build it with (dpkg-buildpackage for example) and install it (pros: it corresponds to installed system; cons: need to install -dev packages, building system, etc. at every need)
- use corresponded auto-built deb from some build system (launchpad or obs for example) by adding repository to apt sources (pros: there's ready to use deb; cons: launchpad - a distinct derivative, obs - (yet) cannot figure out all building options there)

This makes sense if those packages and their components (especially libraries) are not available in Debian repositories at all, or are not shared with other packages that you might install from Debian repositories. Anyway, it is a risky business and you need to know exactly what you are doing.

- maybe there's some better options that I missed at this point

Try to avoid mixing packages from not Debian repositories as much as possible. :wink:

[yvs222]

> This makes sense if those packages and their components (especially libraries) are not available in Debian repositories at all, or are not shared with other packages that you might install from Debian repositories. Anyway, it is a risky business and you need to know exactly what you are doing.
>
there's libs only in dependencies to packages from Debian repository, it's written for own needs (a small gtk4 app), just a bit boring to install-dev-env/build-pkg/install-pkg/remove-dev-env

> Try to avoid mixing packages from not Debian repositories as much as possible.
>
I do in addition to not install 3rd party software especially if there's already the same well-build programs in distro repo packages

[Aristocat]

The only repositories I trust are those supported by major projects that build against current versions of Debian. If it's a random github, I just compile by source.

[stevepusser]

I have used the OBS to build a few packages for various versions of Ubuntu and Debian.

One of our other MX Linux developers has managed to get it to automatically build new versions when he updates his code on github, though that's beyond me.

[yvs222]

I have used the OBS to build a few packages for various versions of Ubuntu and Debian.

One of our other MX Linux developers has managed to get it to automatically build new versions when he updates his code on github, though that's beyond me.

A need of deb building from sources at every installation that's what I tried to avoid.
I've already managed those builds on OBS auto getting sources from github, so that for Debian debs (and OpenSUSE+Fedora rpms) there's repository for apt that can be used, for Ubuntu: Launchpad ones are preferable.

[yvs222]

The only repositories I trust are those supported by major projects that build against current versions of Debian. If it's a random github, I just compile by source.

It was about own package sources (from github for example) to have a handy installation when it's needed. Regarding random sources - I agree, better to be sure what is that.