On 14247 March 1977, Joerg Jaspert wrote: > I've just activated a few changes to the archive we talk(ed) about for a > long time. And while it is not exactly the start of this release cycle, > it should still work out nicely (so one hopes).
Tuesday to now - i think the majority of what breaks with this change should be found by now. > As of now, InRelease/Release files, Packages and Sources no longer > provide MD5Sum and SHA1sums, only SHA256. >From the breakage people mentioned, I think this will change, and the following seems (to me) to be the best way now: SHA1 stay off. But MD5 will come back, until the day we release stretch. Anything later than stretch (and its support suites) will NOT carry MD5sums. That hopefully gives enough time for those places where it's a larger change to get rid of MD5. > Additionally I turned off generating gzip compressed versions of those > files, xz is there. I would have imagined changing a (de)compressor being simpler than possibly adjusting checksums that one may use as a key into a data struct or so. Turns out it does breaks more than I thought. Yet it sounds less serious than the checksums, so - opinions? Keep it xz only? Bring back gz? For how long, til stretch too, or shorter? > To test it, this is limited to experimental. We hope nothing breaks on it, > but lets try for a few days. If that works out, we should adjust > unstable, and another short time later coordinate with the release team > to adjust testing, so it ends up in the next release. Adjusting unstable: I've just turned off SHA1 sums there (next dinstall delivers), compression waits for replies to the above, MD5 for release time. -- bye, Joerg Naturally; worms that don't know what they are doing end up as fish bait, instead of getting invited into weird math experiments. -- Lars Wirzenius