How should you construct a dsc for backports that depends on other
backports packages?

In particular, I'm trying to build something on Jessie. I can build it
no problem but something isn't quite working the way I expect and I
think I need to use jessie-backports for e2fsprogs.

(If there's a right way to do this that doesn't work on Jessie then
that's what I'm looking for, I _can_ solve this problem on Jessie, I
just want to learn how it's supposed to work)


My build-Depends is: (This works fine but pulls in the non-backported
version of a couple of libraries.)
Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool, autoconf, comerr-dev, e2fslibs-dev, libblkid-dev, libbz2-dev, liblzo2-dev, libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid-dev, zlib

I've tried both:
Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool, autoconf, comerr-dev/jessie-backports, e2fslibs-dev/jessie-backports, libblkid-dev, libbz2-dev, liblzo2-dev, libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid-dev, zlib

dpkg-source: error: error occurred while parsing Build-Depends

And setting the version on one or both of the packages:
Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool, autoconf, comerr-dev (>= 2.1-1.43.3-1~bpo8+1), e2fslibs-dev (>= 1.43.3-1~bpo8+1), libblkid-dev, libbz2-dev, liblzo2-dev, libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid-dev, zlib

E: Build-Depends dependency for dump cannot be satisfied because candidate version of package e2fslibs-dev can't satisfy version requirements
E: Build-Depends dependency for dump cannot be satisfied because candidate version of package comerr-dev can't satisfy version requirements

Is there any way to do this just from the control file without pinning?

The versions are available, just not "candidate versions"

comerr-dev:
Installed: (none)
Candidate: 2.1-1.42.12-2+deb8u2
Version table:
2.1-1.43.3-1~bpo8+1 0
100 http://archive.debian.org/debian/ jessie-backports/main amd64 Packages
2.1-1.42.12-2+deb8u2 0
500 http://archive.debian.org/debian-security/ jessie/updates/main amd64 Packages
2.1-1.42.12-2+b1 0
500 http://archive.debian.org/debian/ jessie/main amd64 Packages e2fslibs-dev:
Installed: (none)
Candidate: 1.42.12-2+deb8u2
Version table:
1.43.3-1~bpo8+1 0
100 http://archive.debian.org/debian/ jessie-backports/main amd64 Packages
1.42.12-2+deb8u2 0
500 http://archive.debian.org/debian-security/ jessie/updates/main amd64 Packages
1.42.12-2+b1 0
500 http://archive.debian.org/debian/ jessie/main amd64 Packages

I'm setting up a test to try this on bookworm-backports to see if one of
the above works there and this is just due to really old dpkg-source but
I thought I'd send the above first to ask...

Tim.

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 1 Mar 2026, Tim Woodall wrote:

How should you construct a dsc for backports that depends on other backports packages?

In particular, I'm trying to build something on Jessie. I can build it no problem but something isn't quite working the way I expect and I think I need
to use jessie-backports for e2fsprogs.

(If there's a right way to do this that doesn't work on Jessie then that's what I'm looking for, I _can_ solve this problem on Jessie, I just want to learn how it's supposed to work)

My build-Depends is: (This works fine but pulls in the non-backported version
of a couple of libraries.)
Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool, autoconf,
comerr-dev, e2fslibs-dev, libblkid-dev, libbz2-dev, liblzo2-dev, libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid-dev, zlib

I've tried both:
Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool, autoconf,
comerr-dev/jessie-backports, e2fslibs-dev/jessie-backports, libblkid-dev, libbz2-dev, liblzo2-dev, libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid-dev, zlib

dpkg-source: error: error occurred while parsing Build-Depends

And setting the version on one or both of the packages:
Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool, autoconf,
comerr-dev (>= 2.1-1.43.3-1~bpo8+1), e2fslibs-dev (>= 1.43.3-1~bpo8+1), libblkid-dev, libbz2-dev, liblzo2-dev, libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid-dev, zlib

E: Build-Depends dependency for dump cannot be satisfied because candidate version of package e2fslibs-dev can't satisfy version requirements
E: Build-Depends dependency for dump cannot be satisfied because candidate version of package comerr-dev can't satisfy version requirements

Is there any way to do this just from the control file without pinning?

The versions are available, just not "candidate versions"

comerr-dev:
Installed: (none)
Candidate: 2.1-1.42.12-2+deb8u2
Version table:
2.1-1.43.3-1~bpo8+1 0
100 http://archive.debian.org/debian/ jessie-backports/main amd64 Packages
2.1-1.42.12-2+deb8u2 0
500 http://archive.debian.org/debian-security/ jessie/updates/main amd64 Packages
2.1-1.42.12-2+b1 0
500 http://archive.debian.org/debian/ jessie/main amd64 Packages e2fslibs-dev:
Installed: (none)
Candidate: 1.42.12-2+deb8u2
Version table:
1.43.3-1~bpo8+1 0
100 http://archive.debian.org/debian/ jessie-backports/main amd64 Packages
1.42.12-2+deb8u2 0
500 http://archive.debian.org/debian-security/ jessie/updates/main amd64 Packages
1.42.12-2+b1 0
500 http://archive.debian.org/debian/ jessie/main amd64 Packages

I'm setting up a test to try this on bookworm-backports to see if one of the above works there and this is just due to really old dpkg-source but I thought I'd send the above first to ask...

FWIW I'm getting very similar building a backported package for
bookworm. I did wonder if the problem was needing to upgrade libextfs2
and/or libcom-err2 (on bookworm) but specifying both of those in the
control file doesn't help either:

The following packages have unmet dependencies:
builddeps:/repo/pool/dump_0.4b54-1+1+tjw12r5.dsc : Depends: libcom-err2 (= 1.47.2-3~bpo12+1) but 1.47.0-2+b2 is to be installed
Depends: libext2fs2 (>= 1.47.2-3~bpo12+1) but 1.47.0-2+b2 is to be installed
Depends: comerr-dev (>= 2.1-1.47.2-3~bpo12+1) but 2.1-1.47.0-2+b2 is to be installed
Depends: libext2fs-dev (>= 1.47.2-3~bpo12+1) but 1.47.0-2+b2 is to be installed

Tim.

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2026-03-01 at 11:22, Tim Woodall wrote:

How should you construct a dsc for backports that depends on other
backports packages?

I'm not particularly familiar with this, but I do notice one thing that
may be relevant.

Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool, autoconf, comerr-dev (>= 2.1-1.43.3-1~bpo8+1), e2fslibs-dev (>= 1.43.3-1~bpo8+1), libblkid-dev, libbz2-dev, liblzo2-dev, libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid-dev, zlib

E: Build-Depends dependency for dump cannot be satisfied because candidate version of package e2fslibs-dev can't satisfy version requirements
E: Build-Depends dependency for dump cannot be satisfied because candidate version of package comerr-dev can't satisfy version requirements

Is there any way to do this just from the control file without pinning?

The versions are available, just not "candidate versions"

comerr-dev:
Installed: (none)
Candidate: 2.1-1.42.12-2+deb8u2
Version table:
2.1-1.43.3-1~bpo8+1 0
100 http://archive.debian.org/debian/ jessie-backports/main amd64 Packages
2.1-1.42.12-2+deb8u2 0
500 http://archive.debian.org/debian-security/ jessie/updates/main amd64 Packages
2.1-1.42.12-2+b1 0
500 http://archive.debian.org/debian/ jessie/main amd64 Packages e2fslibs-dev:
Installed: (none)
Candidate: 1.42.12-2+deb8u2
Version table:
1.43.3-1~bpo8+1 0
100 http://archive.debian.org/debian/ jessie-backports/main amd64 Packages
1.42.12-2+deb8u2 0
500 http://archive.debian.org/debian-security/ jessie/updates/main amd64 Packages
1.42.12-2+b1 0
500 http://archive.debian.org/debian/ jessie/main amd64 Packages

The jessie-backports entries here have a priority of 100, where the
other entries have a priority of 500.
It seems plausible at a glance that this might cause the system to
decide that, since there is a version available at a higher priority,
any version available at a lower priority will not be considered as a
candidate for installation.
It might be worth temporarily adjusting the priority of jessie-backports
to see whether that affects the results you get from this.
--
The Wanderer
The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw


--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Sun, 1 Mar 2026, The Wanderer wrote:

On 2026-03-01 at 11:22, Tim Woodall wrote:

How should you construct a dsc for backports that depends on other
backports packages?

I'm not particularly familiar with this, but I do notice one thing that
may be relevant.

Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool, autoconf, comerr-dev (>= 2.1-1.43.3-1~bpo8+1), e2fslibs-dev (>= 1.43.3-1~bpo8+1), libblkid-dev, libbz2-dev, liblzo2-dev, libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid-dev, zlib

E: Build-Depends dependency for dump cannot be satisfied because candidate version of package e2fslibs-dev can't satisfy version requirements
E: Build-Depends dependency for dump cannot be satisfied because candidate version of package comerr-dev can't satisfy version requirements

Is there any way to do this just from the control file without pinning?

The versions are available, just not "candidate versions"

comerr-dev:
Installed: (none)
Candidate: 2.1-1.42.12-2+deb8u2
Version table:
2.1-1.43.3-1~bpo8+1 0
100 http://archive.debian.org/debian/ jessie-backports/main amd64 Packages
2.1-1.42.12-2+deb8u2 0
500 http://archive.debian.org/debian-security/ jessie/updates/main amd64 Packages
2.1-1.42.12-2+b1 0
500 http://archive.debian.org/debian/ jessie/main amd64 Packages
e2fslibs-dev:
Installed: (none)
Candidate: 1.42.12-2+deb8u2
Version table:
1.43.3-1~bpo8+1 0
100 http://archive.debian.org/debian/ jessie-backports/main amd64 Packages
1.42.12-2+deb8u2 0
500 http://archive.debian.org/debian-security/ jessie/updates/main amd64 Packages
1.42.12-2+b1 0
500 http://archive.debian.org/debian/ jessie/main amd64 Packages

The jessie-backports entries here have a priority of 100, where the
other entries have a priority of 500.

Yes, this will work, but I don't really want to do it because if I pin backports at 500 then every single backport package will be considered
for upgrading.

I've worked around this by directly installing the desired packages from jessie-backports and then the above Build-Depends with the explicit
version works.

So this is a half solution, the package will fail to build (well
build-dep will fail) if the relevant packages aren't up to a suitable
version, but does require me to manually install them.

I've had a quick look at apt source to see if I can patch it to accept
the /jessie-backports syntax. I don't think it should be too hard but my
15 minute glance didn't get me much further than an idea of where I'd
need to change it but not exactly how to, nor whether it would be easy
to make it install from backports similar to how apt-get install does.

This particular case, it turns out, is more complicated than I thought, e2fsprogs Pre-Depends on libext2fs2 and so it's not possible even to do
apt-get install libext2fs2/jessie-backports
due to the Pre-Depends and you have to explicitly include e2fsprogs/jessie-backports too to do the upgrade.

I didn't spot the Pre-Depends when I sent the previous emails to the
list, only when I tried manually upgrading the packages did I get an
error message that pointed to the problem. But even specifying
absolutely everything that needs to upgrade doesn't work as it doesn't consider the backports packages.

pinning the backports repo to 500, doing the apt-get build-dep and then removing the pin might be the only solution, but that will in this case,
for example, also upgrade debhelper (which shouldn't matter but isn't
what I'm trying to do). Also autoconf will upgrade. Again I don't think
it should matter in this case, but my goal is to only upgrade the ext2
library to test that change.

Tim.

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 02/03/2026 5:16 am, Tim Woodall wrote:

On 2026-03-01 at 11:22, Tim Woodall wrote:

Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool,
autoconf, comerr-dev (>= 2.1-1.43.3-1~bpo8+1), e2fslibs-dev (>=
1.43.3-1~bpo8+1), libblkid-dev, libbz2-dev, liblzo2-dev,
libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid-
dev, zlib

E: Build-Depends dependency for dump cannot be satisfied because
candidate version of package e2fslibs-dev can't satisfy version
requirements

I've had a quick look at apt source to see if I can patch it to accept
the /jessie-backports syntax.

I do not think it is a bright idea. I expect that pinning specific
packages instead of the whole backports repository should work.

Stuff related to specific distributions or code names should be
minimized in source packages since it increases maintenance burden.

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 4 Mar 2026, Max Nikulin wrote:

On 02/03/2026 5:16 am, Tim Woodall wrote:

On 2026-03-01 at 11:22, Tim Woodall wrote:

Build-Depends: debhelper (>= 9), libncurses-dev, automake, libtool,
autoconf, comerr-dev (>= 2.1-1.43.3-1~bpo8+1), e2fslibs-dev (>=
1.43.3-1~bpo8+1), libblkid-dev, libbz2-dev, liblzo2-dev,
libdevmapper-dev, libreadline-dev, libselinux1-dev, pkg-config, uuid- >>>> dev, zlib

E: Build-Depends dependency for dump cannot be satisfied because
candidate version of package e2fslibs-dev can't satisfy version
requirements

I've had a quick look at apt source to see if I can patch it to accept the >> /jessie-backports syntax.

I do not think it is a bright idea. I expect that pinning specific packages instead of the whole backports repository should work.

Stuff related to specific distributions or code names should be minimized in source packages since it increases maintenance burden.

Perhaps I've hit a peculiar corner case, or perhaps there's a better way
to do this, but I disagree that it 'increases maintenance burden'

If I want to build a trixie-backports package, and that must depend on
another package in backports, then being able to specify:

dependency/trixie-backports

with or without a version and have apt build-dep install from backports,
seems less of a burden than just specifying the version and forcing the
person building the package to work out what to do to build it.

I'm surprised this isn't an existing use case so it's more likely I just
don't know the right magic to make it work.

However, I have a workaround that doesn't need apt changes, and as my particular usecase is for some 'archaeology' on a Jessie system, I'm not
going to investigate further right now.

Tim.

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

If I want to build a trixie-backports package, and that must depend on another package in backports, then being able to specify:

dependency/trixie-backports

with or without a version and have apt build-dep install from backports, seems less of a burden than just specifying the version and forcing the person building the package to work out what to do to build it.

Presumably you say "must depend on another package in backports" because
you've discovered that the version of that other package in Trixie is
too old, and that version in backports is not. Along the way, you have
most likely seen both version numbers, so "work out what to do to build
it" doesn't seem like it would be much trouble.

IOW, I must be missing something.


=== Stefan

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On Wed, 4 Mar 2026, Stefan Monnier wrote:

If I want to build a trixie-backports package, and that must depend on
another package in backports, then being able to specify:

dependency/trixie-backports

with or without a version and have apt build-dep install from backports,
seems less of a burden than just specifying the version and forcing the
person building the package to work out what to do to build it.

Presumably you say "must depend on another package in backports" because you've discovered that the version of that other package in Trixie is
too old, and that version in backports is not. Along the way, you have
most likely seen both version numbers, so "work out what to do to build
it" doesn't seem like it would be much trouble.

IOW, I must be missing something.

Just that

apt-get build-dep mypackage

fails telling you that the package depends on 2.3 but 2.1 will be
installed.

And, afaict, there's no way to resolve this other than either manually installing the package using the /backports syntax or adding a pin so
that the backports package will install by default.

Come back to it in three years time and it won"t necessarily be obvious
that building the package depends on backports at all.

Tim.

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 04/03/2026 11:32 pm, Tim Woodall wrote:

I'm surprised this isn't an existing use case so it's more likely I just don't know the right magic to make it work.

Have you tried to pin *specific* packages (regular and dev packages for
comerr and e2fs libraries) to backports? You might need to run upgrade
before installing dependencies to have runtime libraries from backports.

Perhaps pinning of just dev packages and explicitly installing runtime versions from backports may be an alternative.

I see you were trying to avoid pinning, but in my opinion, it is the
proper way to solve the problem. Of course, increasing priority of the backports repository as whole is risky.

--- PyGate Linux v1.5.12
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)