Re: anna's hard-coded priority list of retreivers
Joey Hess <joeyh@debian.org> writes:
> Goswin von Brederlow wrote:
> > The retrievers should depend on the hardware thats found yet. Until
> > the floppy module is loaded and a floppy drive is found (is anyone
> > working on detecting this?) floppy-retriever should be disabled. As
> > long as no network module is loaded net-retriever should be
> > disabled. As long as no cdrom drive is available cdrom-retriver should
> > be disabled.
> >
> > Actually the net configuration should depend on a net module being
> > loaded and cd-detect on a cdrom driver. That should prevent network
> > configuration or cd searching before its available.
>
> These dependencies already exist for the cdrom and network retreivers.
> Floppy retreiver needs more work; some floppies are scsi devices.
>
> But that does not help with the problem I stated. Main-menu just
> configures the network before using the retreiver.
The configuration should depend on a network card being detected. The
retriver on the configuration beeing completed.
Since in your case the detecting of a network card comes up empty
neither configuration nor retriever should be triggered. I somehow see
this unwanted, unneeded and harmfull triggering of other menu items
when selecting something in main-menu as a big problem. I guess there
are some bugs in there or the code is broken by design. Like main-menu
configuring the kernel-modules when you select "execute a shell", or
your case (might not neccessarily related but feel the same). Its
awfully confusing for the user that selecting A will do some realy
wild things B, C, D, E and fail (which is why you selected A in the
first place).
Another thing. When it has to configure the network it should ask if
it should enable the network retriver. Meaning choose-mirror should
have an "offline" option that prevents the net-retriver from going
around in circles.
> > Secondly it would be better to order them "cdrom, net, floppy" and try
> > each one in turn till one works.
>
> I am sure that no hardcoded order will work for all possible install
> scenarios. We need something more flexible.
If there is a "try and fail silently" scanning is harmless. The
operative word being silently. I don't want it to ask for a cdrom just
because cdrom-retriver is first, but if it finds the right udebs on
the cdrom it should use them.
MfG
Goswin
Reply to: