On Tue, 4 Mar 2025, Nicolas George wrote:
to...@tuxteam.de (HE12025-03-04):
Very often, getting the newer Debian source package (just apt-get source)
and building it (dpkg-buildpackage) after having installed the build
dependencies (apt-get build-depends) is all you need to have a self
built backport. You get a Debian package, so that even your package
manager knows about the "extra" package you just built and installed.
Yes, indeed, you get a Debian package integrated in the dependency
system, which means it can cause problems when a package from the
distribution itself needs to be upgraded.
Huh? Assuming you're building for current stable and taken the source
from testing then you should be fine. Stick a ~version string on the end
and when you migrate to the new stable it will get updated with the
actually version from testing when the release happens.
This is pretty much exactly how backports works. I often backport to
stable rather than stable-backports which means that I get the
backported package installed automatically and everywhere. Only when I
want to limit the backports to certain machines do I use backports.
Backports-sloppy if you want to port to oldstable. It becomes quite
important if you do this to maintain a backport to stable too. While you
can backport to oldstable, I pretty much always use
oldstable-backports-sloppy and require that these packages are
explicitly installed.
That is a terrible idea.
I've been doing this for years and yet to encounter a problem. (other
than the issues you sometimes hit where you have to fix build
dependencies and sometimes code so that a backported package can
actually compile at all on the older version)
So, for example (this is my own system for backporting)
package=squashfs-tools-ng
section=main
distributions=( bullseye-backports-sloppy bookworm-backports )
architectures=( all amd64 )
source_distribution=trixie
patch_description="Backport from trixie"
that is backported to both bookworm and bullseye as there are serious
issues with the version in both distributions. But the upgrade path from
bullseye needs to pull in the bookworm-backports.
package=fuse-overlayfs
section=main
distributions=( bookworm )
architectures=( all amd64 )
source_distribution=trixie
patch_description="Backport 1.13 to bookworm"
That is backported due to a bug in the bookworm version specifically,
there was no need to backport to bullseye. It's in my main repo and so
automatically gets installed if fuse-overlayfs is installed. Which
avoided bullseye machines being upgraded and getting the version from
bookworm because I hadn't added bookworm-backports.
That shows a problem with sticking the version in the description
though - it's actually 1.14 now :-o
$ zcat /usr/share/doc/fuse-overlayfs/changelog.Debian.gz | head
fuse-overlayfs (1.14-1~tjw12r2) bookworm; urgency=medium
* Backport 1.13 to bookworm
-- Tim Woodall <mun...@woodall.me.uk> Tue, 25 Feb 2025 11:37:04 +0000
fuse-overlayfs (1.14-1) unstable; urgency=medium
Neither of these packages appear to have ever been backported which is
slightly surprising given how easy they are to backport.D fuse-overlayfs
I can sort of understand as the bug is exposed in a particularly
convoluted usecase, but squashfs-tools-ng has issues in some simple
cases.
