Matthew Miller wrote: > On Fri, Jun 17, 2005 at 03:05:55PM +0100, Timothy Murphy wrote: >> I wonder if there is something basically wrong >> with the Anaconda development? ... >> >From the little I've seen of it, >> it seems to me excessively complicated, >> and also lacking in clear motivation. > > It's complicated because it's a complicated task. > > And I have no idea what you even mean by "lacking in clear motivation". > The motivation seems pretty clear to me: it's the Fedora Installer. Just to explain a little better what I mean. What exactly is the basic aim of the anaconda developers? In my view, it should be to ensure that Fedora can get to the point of installation on as wide a range of machines as possible. That was always the aim of Linux distributions in the past, with half-a-dozen different boot disks offered for every conceivable situation, together with driver floppies for special devices. I follow the anaconda development mailing list (though not diligently) and it seems to me that most time and energy is expended on what I would regard as secondary matters, while what I take to be the primary aim above is largely ignored. >> Eg should the latest version of Anaconda work >> on any machine the previous version worked on? >> That doesn't seem to me an unreasonable aim. > > It does to me. Eventually, really old hardware and weird situations have > to get dropped, or you get *more* excessive complication and cruft. You > can't have it both ways. I don't think that is true. I would imagine that if changing code at critical points, one could add a clause to the effect that if the new version does not work then one should fall back to the old. For example, the kernel itself seems to be written to this principle. I can't recall anything that used to work in the kernel that has ceased to work (admittedly, after researching choice of modules in some cases). >> I upgrade rather than install because I do not have great confidence >> that the installation will work. >> Eg no installation has worked on a SCSI only machine since Redhat-9. > > Since I install on SCSI-only machines all the time, this is clearly not > true. You (and others) misinterpreted what I said, although it seems pretty clear to me. No installation has worked on one particular SCSI-only machine (in my study) to which I am referring. I am actually responsible for other newer SCSI machines on which there were no problems installing Linux, as far as I know. >> The worst problem with FC-4 was on a machine (Asus motherboard) >> with two SCSI disks and an IDE disk. >> The upgrade seemed to get completely confused about the IDE disk, >> which it could not find. >> I managed to complete the upgrade by using Knoppix >> to delete references to /dev/hda1 in /etc/fstab . > > Deleting references made it work? That seems odd. Anyway, Anaconda is more > conservative with hardware probing than Knoppix is. This is exactly what happened, anyway. I've had problems before when grub became confused about the various SCSI and IDE disks. Basically, I think grub likes to call an IDE disk hd0 unless persuaded otherwise. However, I didn't look into this. All I know is that after upgrading to FC-4, /dev/hda was no longer found, eg by fdisk. >> The upgrade itself on an AMD Athlon64 machine went OK, >> but after it I get innumerable errors >> when trying to compile a virgin kernel. >> Eg "make xconfig" does not work because qtlib is not found. > > This isn't an installer problem at all. This is a > person-building-the-kernel problem. It isn't an installer problem (I didn't say it was) but it isn't a person-building-the-kernel problem either. It is a problem with the x86_64 distribution regarding the libqt library. (There are various versions of this library on the system, and it fails to link to the correct one.) -- Timothy Murphy e-mail (<80k only): tim /at/ birdsnest.maths.tcd.ie tel: +353-86-2336090, +353-1-2842366 s-mail: School of Mathematics, Trinity College, Dublin 2, Ireland
