On Thu, Mar 11, 2010 at 06:09:07PM +0100, Frans Pop wrote: > On Thursday 11 March 2010, Frans Pop wrote: > > On Wednesday 10 March 2010, maximilian attems wrote: > > > applications that still rely on a toplevel /cdrom > > > are likely very buggy and should be kicked. > > > > > > nuke etch compatibility link. > > > > Except that D-I itself still uses it :-/ > > Well, the only usage left were some no longer needed umount statements, so > I've simply cleaned those up as well. > > Committed in SVN.
/cdrom was only obsoleted in etch by a combination of prayer and wishful thinking. apt-cdrom still relied on it until very recently, when Michael Vogt did some work on it. It now has the ability to find CD-ROM devices using libudev, but some tweaks were needed to d-i to cope with that. I committed one extra piece to apt-setup, to make sure that /proc, /sys, and /dev are mounted in /target when running apt-cdrom since otherwise it will be unable to find devices using libudev. Perhaps I have missed something, but Frans' changes seem quite incomplete to me. base-installer bind-mounts /target/cdrom, and configures apt-cdrom to use it; surely that needs to be adjusted if you want to do the detection dynamically there as well, and removing the umounts from most other places while keeping the mount in base-installer looks like a mistake. If you don't bind-mount /target/cdrom in base-installer, how do you ensure that we use the same CD for base installation as was used to boot the installer? While it's a corner case, it's come up in the past when somebody had multiple CDs inserted. I would prefer to keep this facility rather than breaking it, although it doesn't matter whether it's done using /target/cdrom or some other path. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100311172503.ga17...@riva.ucam.org
