Hi a recent thread on the -dak list pointed me back to a topic that I want to have fixed for some time now, which is the location of the installer stuff... (Actually quite some more, but the important part for the boot/release list is this).
I don't think the installer images should be in dists/ as they are now,
but get their own location, installer/. For various reasons, including
the - wth was it added there in the first place, - currently an
installer update move from one suite to another means real
copies/moves. Why, pool/ got rid of that for our packages, why do we
have it for the installer? Also, its really big and doesn't belong into
dists/, which is more like a set of "Package indices".
So the proposed structure I have in mind ends up to look like this[fn:1]:
--8<------------------------schnipp------------------------->8---
installer/
amd64/
20110106+squeeze4+b1/
20120327+b2/
20120507/
20120508/
sid -> 20120508
squeeze -> 20110106+squeeze4+b1
wheezy -> 20120508
i386
[...]
[...]
--8<------------------------schnapp------------------------->8---
There is one drawback I see outright - we no longer have a "current"
link. I might miss something here, but is the current link really
required, if we build it up like the above?
Currently the installer images have their MD5/SHA256SUMS included in the
Release file, so they can be checked and validated against the same key
all the rest of the archive is. We should keep the validation part, but
I am not sure we want to continue listing them in the Release file per
suite.
Instead I think we should have an InRelease[fn:2] file appear in
installer/, which lists all installers checksums files:
--8<------------------------schnipp------------------------->8---
Origin:
Label:
Date:
Valid-Until: (Date+2weeks)
Architectures:
Description: Debian installer images
CHECKSUM1:
12345deadbeef amd64/20120507/images/MD5SUMS
deadbeef54321 amd64/20120507/images/SHA256SUMS
[...]
CHECKSUM2:
12345deadbeef42424242 amd64/20120507/images/MD5SUMS
deadbeef5432142424242 amd64/20120507/images/SHA256SUMS
[...]
--8<------------------------schnapp------------------------->8---
This file would be inline clear signed, just as InRelease files are now.
Timeframe: I would like to change to this new layout pretty soon. Two
weeks? A month? Something there.
For all releases, including the stable stuff, though that needs the RMs
ok, obviously.
To not break whatever trillions of links we have and whatever expects
things in dists/ right now, I propose to move it all over, and set
symlinks from dists/ over to the right installer/ place. That is, dists/
keeps the installer-*/ dirs in main, and the 20XXwhatever/ and current
links are updated to point to the installer/$arch/$foo, where current/
will link to one of sid/squeeze/wheezy.
That way we can benefit from moving gigabytes of stuff out of dists/ but
still have stuff all working. Those links we should then get rid of for
anything >> wheezy. Until then the installer checksums would appear in
the suites release files, as of now.
Obviously I might have missed any number of points here, so now is the time
to beat this down. And/or change the layout to something else, if there
is anything better for it. I mainly move it out of the way of dists/
with this.
Footnotes:
[fn:1] Now, this depends a little if we will ever have installer outside
the main component. We currently do not have that, and I think the
likelyhood of it is very small. Thats why I propose it without a
component in the path entry, but if d-i people say it is more than
possible to actually end up with images for something else than main,
then insert a {main,contrib,non-free} right above the architectures.
[fn:2] I realize InRelease would be a stupid name at that position. And
the fields I propose are more than are strictly needed. I'm all happy
to get talked to drop that and end up with just a file that shows two
checksums for each of the installer checksum files, and be done.
The reason I went with the InRelease one is that tools know them, so
why break out?
--
bye, Joerg
Son, when you participate in sporting events, it's not whether you win
or lose: it's how drunk you get.
pgpSQorndADPc.pgp
Description: PGP signature
