--K

I'll tag this thread solved and continue with the homework due-diligence.

Your time is much appreciated

--K

If I understand policy correctly, I would be asking for a backport of 5.0.2 from testing to be made available for Bullseye in Backports.  If I were the package maintainer receiving that request, my response would likely be something along the lines of "Why are you making more work for me?  Eyes on Bookworm.", because experience suggests backporting a major 5.x.x version to a system built at the time 4.x.x was stable frequently gets hairy.  If that kind of work were the norm, I would expect Backports to be a bit of an unstable mess.

The lxcfs package was backported for the Debian stretch release[1] so it looks possible, at least.

You could even try it yourself:

https://wiki.debian.org/SimpleBackportCreation

^ That would ensure a ~bpo version suffix, which eases transitions between releases.

Yes, that's right.

I would hope so. I think you should submit the patch. See https://www.debian.org/Bugs/Reporting for the preferred method.

There are regular point releases that provides security and other bug fixes without major package version increments. There are some notable exceptions, however: firefox-esr & chromium will both be kept up to date with the respective upstream versions (although chromium can lag a little).

https://wiki.debian.org/DebianReleases/PointReleases

You will also find https://pkginfo.devuan.org/cgi-bin/policy-query.html a useful tool to search for available packages and https://pkgmaster.devuan.org/bannedpackages.txt to know what shouldn't be installed on Devuan . . .

I started looking into backports following RR's suggestion, which lead me to :

https://backports.debian.org/Instructions/

And following the tracker link RR provided, no releases in the vendor 4.x.x branch following 4.0.7 have been added to testing :
https://tracker.debian.org/pkg/lxcfs

It looks like immediately following the 4.0.7 release, the target was moved to 5.0.0 and then to 5.0.2.

If I understand policy correctly, I would be asking for a backport of 5.0.2 from testing to be made available for Bullseye in Backports.  If I were the package maintainer receiving that request, my response would likely be something along the lines of "Why are you making more work for me?  Eyes on Bookworm.", because experience suggests backporting a major 5.x.x version to a system built at the time 4.x.x was stable frequently gets hairy.  If that kind of work were the norm, I would expect Backports to be a bit of an unstable mess.

My perception was that Debian Updates followed software vendor stable releases :
https://linuxcontainers.org/lxcfs/downloads/

• lxcfs-4.0.7 => lxcfs-4.0.8 => lxcfs-4.0.9 => lxcfs-4.0.10 => lxcfs-4.0.11 => lxcfs-4.0.12

But, that seems not to be the case.

When you say "The stable release is so named because the version numbers do not change.", does that mean Updates are more like :

• lxcfs-4.0.7-1 + patches => lxcfs-4.0.7-2 + patches => lxcfs-4.0.7-3 +patches => lxcfs-4.0.7-4

In which case patches are generally limited to bug squashing and mitigating security concerns?

If I were to produce a patch against lxcfs-4.0.7-1 that exclusively corrected the lxcfs presentation of /proc/meminfo ... would that be welcomed within the Debian ecosystem and worthy of an lxcfs-4.0.7-2 package being released?

Perhaps what I am looking for is a grey area between Backports and Updates where the software vendor has addressed minor issues within a major release and deemed a minor release is warranted.  Do these minor releases get picked up in the Debian update cycle?  Or do folks just wait for the next Debian stable release?

Thank you for your time as I build an understanding of the way things work,
--K

how one effectively approaches/advocates/assists toward greater symmetry between stable vendor releases and distribution updates without stepping on toes within the Debian ecosystem.

File a WNPP bug report with Debian to request that the newer version of lxcfs be added to the stable-backports repository.

The stable release is so named because the version numbers do not change.

For my immediate needs I did this :

apt-get install devscripts
apt-get install quilt
mkdir /tmp/lxcfs
chown _apt:root /tmp/lxcfs
cd /tmp/lxcfs/
apt-get source lxcfs
apt-get build-dep lxcfs
wget https://linuxcontainers.org/downloads/lxcfs/lxcfs-4.0.12.tar.gz
cd lxcfs-4.0.7
uupdate -v 4.0.12-1 ../lxcfs-4.0.12.tar.gz 
cd ../lxcfs-4.0.12-1
vi debian/rules

dpkg-buildpackage -us -uc -b

And this produced an "lxcfs_4.0.12-1-0devuan1_amd64.deb" package that I installed and confirmed the /proc/meminfo fix works.  Nice.

So that is great ... for me.  But I'm still at a loss, regarding Debian/Devuan culture (I earned my grey beard in the RPM world), as to how one effectively approaches/advocates/assists toward greater symmetry between stable vendor releases and distribution updates without stepping on toes within the Debian ecosystem.

Is there a Welcome-to-Debian blog somewhere tailored for old transplants?
--K

You might also look it up at tracker.debian.org/pkg/lxcfs for a bit more detail of it's maintenance by Debian.

As for building it yourself, you possibly find some joy with https://backports.debian.org/

https://packages.debian.org/bullseye/allpackages
https://packages.debian.org/bullseye-up … llpackages

The latest stable release of LXCFS, from the detailed changelog, indicates meminfo and swaps are now cgroupv2 aware.  That has value to me as some software I use relies on meminfo to tune itself to available memory :

https://discuss.linuxcontainers.org/t/l … ased/13287

I found the Debian work-needing and prospective packages page, but no mention of updates for LXCFS appear forthcoming :

https://www.debian.org/devel/wnpp/

Is it accurate to say my options are "doing without" or "building my own"?

As a transplant from the RPM-world my question is a bit of an ecosystem/protocol question in the DEB-world.  Can someone educate me as to a proper series of events that should take place to advance a Debian package update?  I'm confident I can roll my own package (having done so in the RPM-world as needed), but that only helps me.

Thanks,
--K