[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dropping Release and Release.gpg support from APT



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.


Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: