Thanks Roberto, and others who tried to explain Backporting, I will need to read this and think about it for a while.
To make comment, I stay away from FlatPacks (the MS world tried this kind of technology once, I wonder if they still do)? I prefer stability and hence Debian Stable with its "not rolling release". Even if I don't have yesterday's release, so far that has not been an issue I cannot get around. Nothing is "secure", just maybe more secure that other ways. Nothing is "stable", just maybe more stable than other ways. Keeping the above two points in mind, keeps me from being too disappointed or arrogant. I am still waiting for "Latest Beta Version: 565.X.X" to move to "Latest Production Branch Version", until then AMD, Radeon video cards it is. https://www.nvidia.com/en-us/drivers/unix/ I will keep reading debian-user to keep updated. George. On Saturday, 18-01-2025 at 13:06 Roberto C. Sánchez wrote: > On Sat, Jan 18, 2025 at 12:14:16PM +1100, George at Clug wrote: > > > > I rarely use backports, but when I do, I like the "adjusted and > > recompiled for usage on Debian stable" part, much better that grabbing > > packages from other distributions and just installing them, hoping > > there will not be issues. Though I had not realised that at times, a > > package would be moved/copied from backports into security, I would > > not have expected that action, but it does make sense when you > > explained it. > > > To be entirely clear, "at times, a package would be moved/copied from > backports into security" is 100% NOT what happens. > > Backporting (at least in the Debian context) has two distinct meanings: > > - a specific patch or set of patches, which are prepared for a given > version of a package, are adapted to an older version of that package > - a newer version of some package is rebuilt for an older version of > Debian (using the older tools and dependencies of that older Debian > version) > > Both of these may happen within the context of a security update, the > second also happens at times outside of a security context. > > For the "specific set of patches" case, many open source projects only > maintain a single active development branch of their project. When a > security vulnerability is announced, they fix it in that active release > branch and then move on with life. > > When that happens, distro maintainers that are responsible for the > security of older versions of these projects are left to grab the > patches from upstream (usually in the form of one or more git commit > diffs) and then adapt those patches to the older version. This activity > is "backporting of one or more specific patches". This is what was done > recently in the case of rsync. > > There is almost never a need to perform this sort of backporting outside > of a security context, though it has happened on occasion. > > As far as the two types of full package backports, there is a security > reason to this and a non-security reason. > > In the case of security fixes, certain projects make dedicated releases > that restrict the fixes on a given branch to security and high severity > bugs. Projects with a good reputation for this and with policies that > align well with Debian's stable release criteria include Mozilla, > Chromium, MariaDB, PostgreSQL and some others. In general, when they fix > a vulnerability, they fix it in all actively maintained branches. When > that happens and those branches include a new release in the same series > as what is in Debian stable (which is often the case), then the security > team is able to incorporate that new version of the package, build it > for Debian stable and release that as a security update (with something > like a +deb12uX version number). > > The other type of full package backport is not for security reasons but > for reasons of wanting a newer version of a package (along with newer > features) in an older Debian release. These packages are provided via > the backports archive, they are not given any security support, and > importantly they do not conform to Debian's stable release criteria. > This means that these packages may have open security vulnerabilities, > and they may have features and behaviors which differ substantially from > what was released in Debian stable. In other words, they may break your > existing whatever (programs you are compiling in the case of a library, > scripts you've written in the case of an interperter, etc). > > Regards, > > -Roberto > -- > Roberto C. Sánchez > >
