On Tue, 17 Jul 2018 17:25:40 +0000 Marco Moller <mmoller@cicbiomagune.es> wrote: > Hello, > I try to understand how and in which situation the established users > opt for the usage of backports - and why meanwhile years old methods > like AppImages (or quite new ones like Snap and Flatpak) are nowadays > not routinely used instead. Don't get me wrong, I am not pushing > against backports, I simply try to orientate myself while digging > deeper and deeper into the world of Linux and Debian, and became > confused. This may be a bit one sided - I only use backports, I don't use the other mechanisms but then that's what should be expected from posting to a mailing list concerned only with backports. TBH I'm not sure how many people would use multiple methods on one machine, especially for servers. These are all tools to get the mix of versions and dependencies that are needed for that machine. There are things to consider for each one but users are expected to make their own choices according to what is available and what works. It will come down to which packages you need at which versions. Most are only available via one of the methods you describe. So choose your method according to what you want the system to do. > Is it because backports are centrally installed for all users, while > the other options are to be duplicated for each single user? I would > not expect that there is a numerous demand for backports of > "optional" or "extra" packages, and therefore would also not expect > the updating local installation of those packages in the user's home > directory to be massy. Most of the time users in search for most > up-to-date packages are anyway not working with the "stable" > distribution, but would right away stay with the "testing" > distribution. I do see the advantage of backports when it is about > the treatment of "essential", "required", "important" or "standard" > packages, though. My perception (and usage) of backports ignores Priority entirely. Backports is to get a newer version of a top level dependency - i.e. a server setup to provide service A will install the package which provides the service and then look for updates of that package to get new features. Security updates will come via the security team and through point releases - machines like these would get new upstream releases via backports. Small fixes for severe bugs can come through to the stable release but those are minimal changes. For a new upstream release, use backports. When the new upstream release needs new dependencies, those get installed from backports too. In the end, these servers will end up with the entire base system as stable + security and then a few carefully selected packages from backports which actually deliver the service required from that machine. In some cases, the backports packages are to support a non-packaged program too. So don't think of backports solely from a desktop user perspective - a lot of backports activity happens to support servers where admins require that the base system is stable and secure but the users need new features. Personally, I wouldn't use stable for a desktop system - I run testing on my desktop and unstable on my laptop, have for some 10 years now. However, all my servers run stable, sometimes with buster in an LXC or VM. > Following the philosophy of that classification, > those packages to me appear better hosted centrally in the system, > and not on a per user base. But updates to "optional" and "extra" > packages, wouldn't this be first class candidates to become addressed > by an Appimage, Snap or Flatpak package, also if an update to an > "optional" or "extra" package would subsequently need an update to a > dependency out of the "essential", "required", "important" or > "standard" packages? These "app containers" are in the end designed > to specially care for exactly this situation to also bring the needed > dependencies, or? > > Is it because a package maintainer should not carry the burden to > also monitor possible issues in the dependencies by publishing the > package update as a backport On the contrary, the uploader of the backport retains responsibility for that backport, including whether that backport continues to work with possible issues in the dependencies. This can be a primary reason why some packages don't get backported - the problems with the dependencies are just too complex to maintain on stable. >, and not having to provide and not > having to care for the dependency as well? I would be surprised if > this would be much hassle, expecting that the maintainer would only > have to release a new app container if indeed such issue in a > dependency would occur and once be fixed by the maintainer of the > dependency package. Here, AppImages might indeed be more risky to > provide, because of the missing mechanism to reach users with > important updates to it. But Snap and Flatpak do autoupdate > themselves, if I understand correctly, and thus appear to be the more > modern approach to deal with this situation of providing updates to > "optional" and "extra" packages for the "stable" distribution, or? Backports can be updated automatically - configure unattended-upgrades. It's not that common though, as the purpose of a backport on my server systems is to provide a service, I plan carefully when that service gets upgraded. -- Neil Williams home@codehelp.co.uk
Attachment:
pgpYG1PruLKPj.pgp
Description: OpenPGP digital signature