On Ma, 12 ian 21, 11:03:06, Michael Grant wrote: > On Tue, Jan 12, 2021 at 10:35:05AM -0500, Dan Ritter wrote: > > Are you running a production system? > > Yes, I guess you could call it production. It's my family & friends > server. In all the time I have been running Debian Testing, I have > never once suffered a serious or protracted disaster as you envision. Is this server accessible from the internet? If so, you really, really should be running stable on it. Really. > Maybe I'm lucky! Little things, yes, like the systemd thing the other > day. On very rare occasions, I have had to pin a package. > > > If so, you should be running buster, and considering moving to > > the next stable release no sooner than a few weeks after the > > transition to bullseye. You should accept security updates as > > soon as is convenient for you, on an ongoing basis. Backports > > are to solve specific issues. > > Hence using buster as an example of today (understand should substitute bullseye after that release): > > deb http://httpredir.debian.org/debian buster main non-free contrib > deb-src http://httpredir.debian.org/debian buster main non-free contrib > > deb http://security.debian.org/debian-security buster/updates main contrib non-free > deb-src http://security.debian.org/debian-security buster/updates main contrib non-free > > deb http://deb.debian.org/debian buster-backports main contrib non-free > deb-src http://deb.debian.org/debian buster-backports main contrib non-free > > Is it then possible to add the /testing line to be able to > occasionally pull in specific packages from testing? I think I would > need a preferences.d/something.pref file. > > deb http://mirrors.linode.com/debian/ testing main contrib non-free > deb-src http://mirrors.linode.com/debian/ testing main contrib non-free > > Clearly if the package I wanted to install from testing would suck in > a lot of dependencies, then I likely would not do that, but I don't > want it to suck things in from testing automatically otherwise, I am > then running testing. > > Is this setup possible or am I really just going to have to be patient > if something isn't in backports? Anything is possible (hey, it's a big world), though not necessarily a good idea. Installing packages from testing on stable is completely different than installing stable-backports on stable, even if the packages in stable-backports do come from testing. The packages in stable-backports have been recompiled for stable by someone with experience in Debian packaging, at a minimum. Depending on the package additional changes might be needed as well, due to different packages / versions of other packages in stable compared to testing. If you really, really need a package from testing that is not available in stable-backports the first thing to do is to ask for a backport on debian-backports (with Cc: to the package Maintainer, in case they might be willing to provide it). Of course, this implies the package provides valuable new *features* that are otherwise not available in stable. Bugs in stable should be fixed via stable-updates (point releases). In case no one is willing to provide a backport you can try doing the backport yourself, e.g. by recompiling the package yourself in a clean stable chroot. If successful you could even look for a sponsor to upload the package to stable-backports ;) See https://backports.debian.org/Contribute/ for more details. If none of the above is feasible and you really, really need the versions in testing (for a server? care to provide more details?), in my not so humble opinion you are better of running testing, with select packages from unstable (for security reasons only). This will involve tracking potential security issues yourself, as the DSAs don't cover issues that are only present in testing and/or unstable (though they do cover security issues that are present in stable and also in unstable, so it's a start). Hope this helps, Andrei -- http://wiki.debian.org/FAQsFromDebianUser
Attachment:
signature.asc
Description: PGP signature