Bug#848194: Want way to get Release (or InRelease) file from cache
David Kalnischkies writes ("Re: Bug#848194: Want way to get Release (or InRelease) file from cache"):
> On Sat, Dec 31, 2016 at 01:25:33AM +0000, Ian Jackson wrote:
> > I get a sense from your mail that I may have irritated you.
>
> You haven't,
OK, good.
> > Otherwise I can try to explain again why I think I need the suite
> > codename, and try to explain my thinking about some of the things that
> > seem wrong to you.
>
> You don't need to. It is enough if you know the answer – I don't
> need to know, for me its enough if someone knows. I was 'only'
> advising against rushing into it,
Well, I don't want to implement something wrong. You know much more
than I do about the way apt chooses which package to get from where.
I don't want to impose on your time but if you're willing I still feel
there is room for me to get to a better understanding about what dgit
ought to do in this area.
So in that spirit:
> My entire knowledge of dgit and the problems it solves are hence based
> on your bugreport and the manpage you referred to. That isn't a lot, so
> in my mind I replace dgit with 'apt source' and imagine wanting to
> implement such a feature for that.
The most salient difference is that dgit needs to choose a git branch
name. dgit's usual approach is to name branches after suite codenames
(eg `refs/heads/dgit/jessie'). Each of these branches is
fast-forwarding (by use of pseudomerges[1] if necessary).
If the user says `dgit clone dpkg RUNNING' dgit has not only to
generate a git tree, once off, the same way `apt source' would
generate an unpacked source tree. It also has to put that new git
working tree on a particular branch. Then, in future, a suitable
`dgit pull' rune ought to update that branch.
Suppose that in between `dgit pull' runs, the user does `apt-get -t
jessie-backports install dpkg' and then `apt-get -t jessie install
dpkg'. I don't think the user wants a single git branch which
contains a fast forwarding sequence of commits whose contents flap
between jessie and jessie-backports.
Rather, jessie-backports ought to be its own git branch.
The user who switches between jessie and jessie-backports for a
package should see those as two git branches, which they are looking
at alternately.
This is why the version number, or the .dsc, is not sufficient. We
want something with some kind of historical continuity. The suite is
a thing which exists outside the user's system and contains a series
of updates for particular package(s) - ie, conceptually is very like a
branch. (Indeed the Debian BTS calls them `branches'.)
Does that make sense ?
> The bugreport here will be used for having the 'Release' file be part of
> that interface itself. In all likelihood that will be well after stretch
> through as we should first solve the problem of having InRelease
> sometimes called Release… but that isn't blocking you as the bits you
> want from it are available 'elsewhere' already.
Thanks. I think this will all have to wait until after stretch in any
case.
Ian.
[1] A `pseudomerge' is a merge which exists not to change the code but
only to make a branch fast-forwarding. Its tree is identical to that
of one of its parents; the others do not contribute to the contents at
all. Eg, the result of `git merge -s ours'.
--
Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Reply to: