Re: Bug#93612: Support for new archive structure
On Sat, 14 Apr 2001, Raphael Hertzog wrote:
> Le Sat, Apr 14, 2001 at 02:05:35PM -0600, Jason Gunthorpe écrivait:
> > How exactly do you propose that apt-cdrom determine that these two random
> > trees of stuff are actually the same tree of stuff? Current apt-cdrom will
> > not properly handle CD's made like this, so you've broke that.
> Explain us how apt-cdrom works then ... what is it looking for ?
It looks for all files names Packages or Packages.gz on the CD, uses
inodes to infer which are refered to by symlinks, then probes the
Packages file and attempts to infer any necessary corrections to the
Filename fields and removes any records that don't exist, then it uses
various algorithms to determine the most compact 'deb' line(s) for the
disc.
Having more than one tree means it will be detected more than once and
that certianly is not desirable, any may cause problems, like it asking
for the disks in a non-ideal order, or something equally lame.
> And it's what I'd call an exception to the general rule, no ?
What? That you want to make discs that don't work with any apt-cdrom that
exists? That sounds like a pretty bad thing to do.
> BTW, you could use the information in the "Release" file to know that they
> are the same, no ?
No. It is entirely reasonable for someone to make a Release file for a
non-debian component that has the same characteristics as the Debian one.
This would then let the various apt pinning mechanisms work consistantly
over the entire CD.
> > Frankly, I have no idea how I'd make it able to detect this that doesn't
> > end up being excessively difficult.
> And what happens if it doesn't detect it ? What's the problem of having
> both tree discovered by apt-cdrom ? One will be signed by a public key and
> will therefore be trusted and would logically take precedence over the
> non-signed tree. Doesn't that sound logical ? ;-)
It will add them both and it becomes trivial for someone to defeat the
security mechanisms. The insecure one must be ignored for things to work
correctly.
I *really* don't see why this is necessary. How is writing:
deb file:/.../ woody-secured main
any better than writing
deb-partial file:/.../ woody main
?
Even with this scheme you still need to have the 'deb-partial' feature!
Consider with AJ's case that you want to use security, and file/http
URI's, you *still* need to have the original release file, the complete
package file and the reduced file list and you still need APT support to
combine all that information.
All this proposal does is break apt-cdrom, in a way that I probably can't
fix, and that makes it far worse than everything else that has been
proposed!
Step back and look at why you are doing this - the only reason is so that
people using old APTs can continue to use file: URIs and loopback mounts
and not use -m! Those people are so few that it is not unreasonable to
expect them to upgrade to a new APT and change their sources.list
slightly. Nothing they already have stops working.
We've done much, much worse things to our users, this is not a big deal!
Jason
Reply to: