Re: apt 0.6 in experimental

[Matt Zimmerman <mdz@debian.org>]

On Sun, Dec 28, 2003 at 01:18:22PM -0800, Matt Zimmerman wrote:

> On Sun, Dec 28, 2003 at 01:32:47PM -0500, Joey Hess wrote:
> 
> > With apt 0.6.1, I have this in sources.list:
> > 
> > deb http://http.us.debian.org/debian/ ../project/experimental main contrib non-free
> > 
> > I thought that apt was supposed to auto-pin experimental to not upgrade
> > to packages in it automatically. However:
> > 
> > joey@dragon:~>apt-cache policy diff
> > diff:
> >   Installed: 2.8.1-6
> >   Candidate: 2.8.4-0.0
> >   Version Table:
> >      2.8.4-0.0 0
> >         500 http://http.us.debian.org ../project/experimental/main Packages
> >  *** 2.8.1-6 0
> >         500 http://http.us.debian.org unstable/main Packages
> >         100 /var/lib/dpkg/status
> > 
> > And indeed it wants to download diff and several other packages from
> > experimental. I downgraded to apt 0.5.17, and it behaves the same. Am I
> > wrong about the default experimental pinning?
> 
> OK, I can reproduce this.  The problem is that it is looking for
> experimental/binary-$(ARCH)/main/Release (which isn't downloaded) rather
> than experimental/Release (which is).  This might require some changes, but
> is fixable.

So here's the deal.

apt 0.5 downloads dists/<dist>/<section>/<binary,source>/Release for use in
policy calculations.  apt 0.6 does not download that file at all, and
downloads dists/<dist>/Release for use in authentication.  However, 0.6
still tries to read dists/<dist>/<section>/<binary,source>/Release, which
has not been downloaded.

This could be fixed one of two ways:

1. Use dists/<dist>/Release for both purposes (authentication and pinning).
This is trivial, and works fine for the Debian archive (dists/<dist>/Release
is more or less a superset of
dists/<dist>/<section>/<binary,source>/Release), but could have unknown
effects for third-party repositories which provide per-section Release
files.

2. Continue to download them all.  This requires some further changes to the
apt-secure code.

Personally, I find the distinction between these two types of Release files
to be confusing, and would prefer (1) as it is much simpler.  However, I
don't know whether there is a rationale for why things were done as they
were for apt-secure, and whether the top-level Release file is intended to
replace the others.

Suggestions?

-- 
 - mdz