On Wed, Dec 03, 2003 at 10:24:54PM -0500, Joey Hess wrote: > > (A nice UI might be something like: > > cando="" > > for x in oldstable stable testing unstable; do > > cn=$(wget -q -O - $MIRROR/dists/$x/Release | sed -n 's/^Codename: //p') > > if [ "$cn" -a -e "/usr/lib/debootstrap/scripts/$cn" ]; then > > cando="$cando $x=$cn" > > fi > > done > > echo "I can try to install:" $cando > > echo "Which one do you want?" > > but that's only possible if d-i has the Release files itself.) > I think some of our users do not like to have to choose between code > names. Anyway, d-i will not support oldstable,
When sarge becomes oldstable, it will, though. Instead of the last
couple of lines, consider instead:
if [ "$cando" = "" ]; then
echo "Sorry, can't install anything."
else
codename=""
while [ "$codename" = "" ]; do
echo -n "I can try to install: "; echo $cando | sed 's/=[^ ]*//g'
echo -n "Which one do you want? "
read suitename
for x in $cando; do
if [ "${x%=*}" = "$suitename" ]; then
codename="${x#*=}"
fi
done
done
echo "debootstrap $codename /target ..."
fi
The user just has to talk about suite names, and d-i can automatically
select the right name for whichever suites can actually be installed
(testing currently, stable when sarge is released, oldstable when sarge+1
is released). More interestingly, d-i can indicate which suites are
actually able to be installed, no matter what happens to the archive
-- if there are major changes that drop the Release files, then it'll
accurately say "Sorry, can't install anything" and the user won't waste
his time trying to use an old installer against the archive.
> Of course I will put some codename lookup code in d-i if you insist, but
> there are many things I dislike about the idea:
> - We will then have one more program that has to be able to parse
> release files. If you posit they could change format later, then
> we're creating more work for ourselves later on.
d-i needs to change each release anyway; debootstrap does too, but its
API doesn't.
> - Similarly, this will be one more program that has to validate
> release files. It would perhaps be nice if debootstrap became able
> to check their signatures along with their md5sums. It would be
> annoying to have to duplicate that code into d-i too, and this is an
> area that seems more likely to change than Release file format.
I'm more inclined towards having a pre-verified Release file get passed
to debootstrap than to have debootstrap use gpg, really. Establishing a
trust chain is Hard, and isn't something you can do well without a UI -
which debootstrap doesn't have.
> - d-i will also have to add code to handle every URI type that
> debootstrap does, including new ones if they are added to
> debootstrap. This is also an area that seems likely to see future
> change.
Erm, d-i calls debootstrap; it knows exactly which URI types it's going to
use to invoke debootstrap.
> - While my patched debootstrap does download the Release file twice,
> it should be much easier to optimise that to one download than if
> the first download happens in a separate program in d-i.
As above -- all that means is that d-i has to pass the Release file
it downloaded to debootstrap. It can do that now by dumping it in
$TARGET/var/lib/apt/lists, but if it's actually going to be used, we'll
set up a simpler way. Anyway, downloading a Release file twice isn't a
big deal.
> - I admit it: I have a time or two accidentially given debootstrap a
> symbolic release name and been suprised to see it fail. Putting the
> code in debootstrap makes it that little bit easier to use.
That's a valid point; nevertheless, I'd still much rather see d-i do this
itself /first/, 'til we can definitely see that it's workable and a win.
> It feels like we'd have to become more and more intimately connected
> with debootstrap, while at the same time replicating more and more of
> what debootstrap does, if this were done in d-i and not in debootstrap.
Another option would be to provide a separate "debootstrap_dload" script
that can get a Release file, or Packages file, or .deb, or URL for you in
the same way debootstrap does. But again, I don't want to go increasing
debootstrap's API without being sure it actually is a good idea.
And I do think there are other wins in having d-i access the Release
files itself.
Cheers,
aj
--
Anthony Towns <[EMAIL PROTECTED]> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
Linux.conf.au 2004 -- Because we can.
http://conf.linux.org.au/ -- Jan 12-17, 2004
pgp00000.pgp
Description: PGP signature
