On 29/04/16 16:36, Robert Lange wrote: > I have made such a backport in my personal Jessie backports repo. I > used the source packages from testing (and maybe unstable, if a > package was not in testing, but I think all relevant packages are in > testing now). The process was complicated b/c I needed to backport > dpkg and debhelpers and a bunch of others in order to satisfy the > dependency chain and build dependency chain. However, after compiling > around 10ish source packages, everything worked. I've been tracking > and keeping up w/ changes, and so far I have not had any problems, > with the following caveats. > > One major issue with an official backport is that GnuPG 2.1 breaks > backward compatibility with the key format of previous versions. This > is not a problem if you can use gpg2 for everything, but if you still > need gpg1 for some things, then you will have to manually keep 2 > copies of your keychain in sync; the old 1.x format and the 2.1 > format. Every time you import or sign a new key, you will have to > remember to do the operation with both gpg and gpg2. For me, I have > been able to live with 2.1 only, but others may not be able to. > > This is made somewhat more complicated by the fact that many Debian > admin and build scripts currently still default to invoke gpg instead > of gpg2. I had to set some environment variables to get some scripts > to use gpg2, and I think I had to set up a diversion for some other > scripts that are currently hard-coded to use gpg instead of gpg2. (I > am not at home currently, so I can't be more exact.) There were some > warnings about gpg2 having possibly incompatible command line > arguments and maybe some scripts breaking as a result of this, but so > far I have not noticed any problems from this. > > Anyway, upgrading my personal machines to GnuPG 2.1 was interesting > and rewarding, but given the above, I would say that doing this in the > official backports repo would cause a lot of problems, especially with > that special breed of user who upgrades first and reads the notes later.
Thanks for this feedback My reason for this is the PGP Clean Room Live CD: https://wiki.debian.org/OpenPGP/CleanRoomLiveEnvironment and users of the CD would not necessarily be impacted by the dependency issues or the backwards compatibility issues. However, I agree that regular users of backports could be surprised by these compatibility issues. I wonder if we need a jessie-backports-experimental for things that could be troublesome like this. Regards, Daniel