On Fri 05 Jan 2007 21:33:44 NZDT +1300, Andrew Packer wrote: > Decided to update logcabin from FC 4 to Ubuntu 6.06 to be consistent > with our other machines. Result: Ubuntu repartitioned the (SATA) disk > but then couldn't recognise any of the partitions.
> Now FC 6 boots but X doesn't. I have to login as myself, su - to root, > rm a lock file, exit to myself, startx and we're happy for a while. The > system runs with the vesa generic driver; the graphical display > adjustment tool shows the existence of the Intel (on-board 945GM) driver > but won't install it (but would, apparently, install it for a second > display - ???). Otherwise all's well until shutdown looms - at log-out > I just don't get the option of shutting down, and even if I exit to a > shell and invoke shutdown now, the power stays on. > I miss dpkg, apt-get and synaptic! And that would guarantee to give you a working system? That's naive. Just look at your Ubuntu. ;) Even if one assumes for a momement, and without reason, that the packaging system (installation, verification, search, dependency resolution, security etc) works fine, it is obvious that it does nothing to ensure the software installed by the packages actually works as you want it to, or even as intended. It's only the Debianists who spread that confusion. Having a good deal of first-hand experience with dpkg&Co, I can say that dependency resolution works well, handling multiple repositories works well, a source package format is simply non-existant, package verification is cumbersome for package files and non-existant after the package is installed, and searching had some absent feature(s) (have to check my notes here). Overall it doesn't beat rpm&Co, which has very good package formats and verification before and after installation. Dependency resolution is a "depends". Works extremely well on SUSE if you stay within distro and use the distro-supplied tools. Works well in general if you use tools like yum, smart or whatever else. Success with third-party package repositories has not much to do with dpkg&Co vs rpm&Co and a lot to do with how well the packages in the repository are matched to the distro which you're trying to force-feed them into. If you stay with Redhat-based distros you won't have any more trouble with Redhat-based package repositories than you have with Debian-based distros and Debian repositories (and I had a lot of trouble with the Debian side there too - in fact I can't spot any difference). However, there are quite a few rpm-based distros which are not Redhat-based, whereas all the common dpkg-based distros are Debian based. Which means two things: 1) The perceived lack of trouble with package handling is hardly due to dpkg, but to the Einheitsbrei[1] of parts put together, 2) If I am looking for a good distro, the dpkg-based ones have a few new applications and some good ideas on a foundation which is evolution-arrested in 1996. Which is very unfortunate (though can be an advantage on systems with 32MB of memory). Oh and package building is a pain times two however way I look at it because source code is so un-uniform, requiring a very individual set of steps to knock it into binary installed. And the first thing you have to do regardless of packaging format is to find a fully automated (i.e. shell script) way of making make + make install work. Which takes 95% of the time. Your FC6 problems wouldn't be solved by dpkg. "FC6 is buggy, therefore rpm is cr*p" deserves no further comment. The Intel 945 graphics concoction is a major pain in the rear across all things Linux right now. I didn't follow the solutions, if any, as I don't have the hardware (thank goodness). No doubt that'll be solved in time, as that chip seems to be very popular now. For now, google a lot, and post a summary (in new thread). I have a box now too where the power stays on after shutdown, though the disk is turned off. The box has possibly a buggy bios anyway, though it was working before I upgraded to kernel 2.6.18. These things are apm/acpi related, and construction of PC hardware in that department is a bane for any software which hasn't been cludged up by the mobo/bios manufacturer. As such, it is likely kernel dependent, as well as dependent on the kernel mods made by $DISTRO. Play with your bios settings as well as kernel options in the acpi area. Use google, though don't expect success. HTH, Volker (who'll leave his computer alone until the weather packs up) -- Volker Kuhlmann is list0570 with the domain in header http://volker.dnsalias.net/ Please do not CC list postings to me.
