Dropping Release and Release.gpg support from APT

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Dropping Release and Release.gpg support from APT

Julian Andres Klode-4
So,

we currently have code dealing with falling back from InRelease
to Release{,.gpg} and it's all a bit much IMO. Now that buster
has been released with an InRelease file, the time has IMO come for
us to drop support for the old stuff from APT!

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

My idea being that we give this a cycle in the Ubuntu 18.10 stable
release before we drop it, so people are ready for it.

Why remove it?
--------------
* It's annoying UX to have repositories with Release files and the "Ign" lines
* Handling the fallback from InRelease to Release{,.gpg} involves some abstractions
  and logic and the less logic we have in security-relevant file fetching, the better

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Philipp Kern-2
On 2019-07-10 10:04, Julian Andres Klode wrote:
> 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
[...]
> 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.

Given the timeline, shouldn't we also get oldstable to ship an InRelease
file?

Kind regards
Philipp Kern

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Julian Andres Klode-4
On Wed, Jul 10, 2019 at 10:10:41AM +0200, Philipp Kern wrote:

> On 2019-07-10 10:04, Julian Andres Klode wrote:
> > 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
> [...]
> > 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.
>
> Given the timeline, shouldn't we also get oldstable to ship an InRelease
> file?

What's the use case for having oldstable in your sources.list on
unstable/testing machines?

But yes, I think it would make sense to ship an InRelease file
with 9.10 now that we are capable of having those.

--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply | Threaded
Open this post in threaded view
|

Re: Dropping Release and Release.gpg support from APT

Ben Hutchings-3
On Wed, 2019-07-10 at 10:17 +0200, Julian Andres Klode wrote:

> On Wed, Jul 10, 2019 at 10:10:41AM +0200, Philipp Kern wrote:
> > On 2019-07-10 10:04, Julian Andres Klode wrote:
> > > 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
> > [...]
> > > 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.
> >
> > Given the timeline, shouldn't we also get oldstable to ship an InRelease
> > file?
>
> What's the use case for having oldstable in your sources.list on
> unstable/testing machines?
I currently have "deb-src ... jessie main" in my sources.list so I can
fetch packages that (might) need a security update.

Obviously I build them in a jessie chroot, but it seems like overkill
to do that for the initial source download too.  And back when I was
doing triage for Debian LTS I wouldn't build at all - I would only look
at the source to see if a bug was present in the old version.

Ben.

> But yes, I think it would make sense to ship an InRelease file
> with 9.10 now that we are capable of having those.
>
--
Ben Hutchings
One of the nice things about standards is that
there are so many of them.



signature.asc (849 bytes) Download Attachment