Anthony Towns wrote:
> > Surely all suites that are currently referred to by testing, unstable,
> > and stable have release files and will continue to have them for the
> > forseeable future.
>
> The forseeable future doesn't even extend to the next release...
>
> Putting it in debootstrap makes it hard to drop in future -- any app,
> like d-i, that happens to say "debootstrap testing" is going to complain
> if that breaks -- whereas putting it in d-i makes it easy to drop if
> this turns out to be a bad idea.
I'm having difficulty thinking of a scenario that would involve changing
release files in a future release in a way that would not require
changes to the current debootstrap, but would require changes to
debootstrap+my patch. The only one I can come up with involves dropping
or changing the Codename field in the release file, while leaving the
rest of the format compatible with debootstrap. Which seems unlikely if
debootstrap begins using the Codename field.
I wouldn't mind particularly (despite my last point below) if the
codename mapping in debootstrap were only enabled in --debian-installer
mode. Sure, you drop it later and d-i must also be changed, but if it
turns out to be that bad an idea, we'd be changing d-i anyway..
> (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, and AFAIK every mirror in
Mirrors.masterlist has all the other suites, so this probing is
unnecessary.
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.
- 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.
- Similarly, this will be another program hard-coding the archive
layout, which is another thing that seems likely to change
eventually.
- 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.
- debootstrap may choose a particular program (eg, wget) to retrieve
release files for some specific reason, and d-i has to then track
those reasons, and probably use the same program to ensure that it gets
the Release file in all cases debootstrap does. Of course this is a
weak argument, since d-i has to track what programs debootstrap uses
anyway, to have them on the initrd.
- 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.
- 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.
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.
By the way, I forgot to check my patch for tainted data problems. A
better version replaces the sed in the get_release_suite function with
the following:
sed -n 's/^Codename: \([a-z]*\)$/\1/p' < $reldes
--
see shy jo
Attachment:
signature.asc
Description: Digital signature