On Fri, May 19, 2017 at 7:31 PM, Richard Owlett wrote: > 1. At _this point_ in the release cycle is there reason to prefer URLs > specifying "stretch" over ones with "testing"?
The only difference between URLs containing stretch vs URLs containing testing, is that, *in the future*, testing URLs will point to buster and then bullseye and then the other future releases while stretch URLs will eventually be obsoleted and archived and some stretch URLs will no longer work. At this point in time, there is no difference between the two but if you are storing the URLs somewhere then you should be aware of the difference and choose the one most appropriate for your context. > 2. Is there a document (or blog or ??) targeted at someone using a "testing" > release for the first time. My interest relates to the move from MySQL to > Mariadb - I've already been pointed to links to the fine details of the > change. I'm asking if there something with a broad perspective on dealing > with any testing release. Our official documentation is available here: https://www.debian.org/devel/testing https://wiki.debian.org/DebianTesting I wrote a blog post about using testing (some of it is out of date now): http://bonedaddy.net/pabs3/log/2012/10/29/thoughts-on-debian-testing/ Probably the biggest recent change is that I moved away from equivs towards generating a real package with debhelper, into which I install all the configuration snippet files and extra scripts that I have. In particular I've added a debsecan-based security update mechanism: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725934#20 It isn't perfect but helps avoid manually picking security fixes from sid. I fairly recently switched to unattended-upgrades and also installed needrestart and needrestart-session so that I'm not manually doing security upgrades and daemon restarts and get pinged to restart apps with upgraded libraries. -- bye, pabs https://wiki.debian.org/PaulWise
