Re: Dropping Release and Release.gpg support from APT
On Wed, Jul 10, 2019 at 10:35:25AM +0800, Paul Wise wrote:
> On Wed, Jul 10, 2019 at 2:53 AM Julian Andres Klode wrote:
>
> > Timeline suggestion
> > -------------------
> > now add a warning to apt 1.9.x for repositories w/o InRelease, but Release{,.gpg}
> > Aug/Sep turn the warning into an error, overridable with an option (?)
> > Q1 2020 remove the code
>
> I think this timeline is missing a few items:
>
> File bugs/patches on dak, launchpad, reprepro and other repository
> creation tools to drop producing Release{,.gpg} (including all the
> ones used by derivatives and by prominent external apt repositories
> and apt repository services).
>
> Wait for all of those to be fixed.
We don't need them to do that. Repositories can still ship the old
files :)
We do need them to ship InRelease files. I just filed an issue for OBS
to do that. Given how long we had InRelease file, and how confusing it
is to not provide InRelease files (not to mention that it doubles the
traffic for no-change cases), I'm surprised they aren't using InRelease
files yet.
Also like we've been talking about dropping Release.gpg support
and listing the InRelease file as mandatory in the repository format
spec for ages, so this should hardly come as a surprise to anyone.
>
> Add the warnings.
>
> Wait one Debian release cycle.
I don't think it provides a significant benefit - we'll have plenty
of other breakage in 2 years time. Like we started APT 2.0 development,
there is probably quite some more stuff that's going to break. Like
package names might suddenly have a different meaning when we get
patterns or stuff like that (something we do really have to fix, currently
apt install g++7 would install a ton of packages involving gs and a
7 somewhere in their name if there is no g++7). I think InRelease is
the least of our worries.
Basically we have three types of users:
1. The average user, using the debian repo and a bunch of popular
third-party ones (e.g. spotify, chrome)
2. The power user who builds their own repository
3. Organizations building their own repositories
Let's see how this affects them when they upgrade to bullseye:
1. The average user mostly uses the same third-party repositories
as an Ubuntu user. Those will be fixed because they've already
been causing warnings/errors in an Ubuntu stable release.
2. The power user will likely be running testing/unstable and have
already fixed their repository, or at the very least do so now.
3. The organization will run upgrade tests prior to upgrading, note
their repositories stopped working, and fix them before rolling
out the update.
In summary, I do not expect Debian users to be really negatively
impacted by that change.
In any case, we'll see what breaks when we add that in 1.9.x, and
if there's still significant damage left we can potentially extend
the grace period for periods of 3 months or so, but I definitely want
this to be over when bullseye releases.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: