On 10/29/2016 09:27 PM, Michael Meskes wrote: >> - The parallel use of release 1.0 and 1.1 will not be pursued? >> >> - Why is the transition started with 0 (zero) good packages (from > 552)? >> ... > > May I add one more, and actually pretty pressing question? How are we > supposed to upload "fixed" packages? > > I have two that are said to be removed in, like, 12 days. If I upload > those to experimental, it will not prevent the auto-removal. Uploading > to sid will make the packages uninstallable for obvious reasons. And > then there's the "transition freeze" in 7 days. > > Let's say I'm a bit confused. Could anyone please tell me how this is > supposed to be handled?
Well, ideally it'll compile with both OpenSSL 1.0.2 and 1.1 and therefore be binNMU-able. (This has the advantage that such a patch is much more likely to get accepted by upstream.) In that case you can upload a version that Closes: #nnn the RC bug. When I initially packaged open-isns I did have the looming OpenSSL transition on my mind, so I added a to makes open-isns build against both 1.0 and 1.0.2 (and also 1.0.1, for backporting to Jessie) before the very first upload to sid. Once the SSL transition gets started, the release team will just have to binNMU the package once openssl 1.1 is uploaded to sid. (Also, if you ever want to backport stuff to jessie-backports, it is necessary to still support building against OpenSSL 1.0 even after the transition. That's not something relevant for all packages, as not everything is going to be backported, but there are definitely some packages that will be affected.) If you're interested in how that can look like: https://anonscm.debian.org/cgit/pkg-iscsi/open-isns.git/tree/debian/patches/openssl-1.1.patch The patch is about the same complexity as a (hypothetical) patch that just makes the software compile against 1.1 whilst dropping support for 1.0. Granted, open-isns is not a heavy user of OpenSSL, so YMMV here. Regards, Christian
