I think this is a solid feature request and I've spent a month or so looking into a good solution.  While I don't have a patch of my own yet, I disagree with the method Raseel used to solve this issue.  Basically there is nothing guaranteeing multiple CD-ROM devices will be named /dev/cdrom1-9.  This is simply a convention used by most (if not all) distros.  I believe eject's behavior should not make assumptions about the existence of or the configuration of udev.

Most of the following I wrote a before Raseel's comment, so bear with me if it reads awkwardly.  Basically the following is just my thoughts on different approaches I could take to implement this feature request:

First, I did confirm that eject will not "just work" if /dev/cdrom does not exist.  However, I haven't confirmed the udev assignment portion of this bug, so for right now I am going to leave this bug as unverified.

One thing I keep going back and forth on is if this is an error with udev or eject.  One possibility is to make /dev/cdrom a non-persistent device name and have it point to the first detected CD-ROM on the system.  However, udev has been around for about 5 years now and there might be many applications that depend on /dev/cdrom being a persistent name for a device.

Looking at eject now, I think the best thing to do is determine how many optical drives are connected to the system.  If the number of optical drives is greater than 1, refuse to eject.  If the number of optical drives is one, then automatically eject that device.  The eject command is obviously created with the intention of mainly interfacing with CD-ROMs, so if you have no optical drives but there is another ejectable device that the eject command can interface with, eject should ignore that device unless it is explicitly specified.

So, the problem becomes determining the number of optical drives in the system.  It was suggested by Bryce that we look for /dev/cdrom[1-9].  While most systems name their CD-ROMs in this manner, this naming is entirely based on udev rules that may not be consistent across all distributions.  Hence, (as I said above) I don't think this is the best solution for this problem.

Bryce also suggested that /proc/sys/dev/cdrom/info be used.  One advantage to using this file is that it uses the CD-ROM capabilities flags that are set when the drive is registered.  The file appears to access these flags without opening each device which means the output is extremely reliable and probably renders extremely fast.  However, from the research I did, proc is suppose to be used just for process information and the use of non-process related files in proc is deprecated.  Also, there is a chance that the user did not include the proc file system in his/her kernel (although the chances of that are pretty low).  Finally, the file is formatted in a human readable format and is not formatted for easy parsing (although parsing the file wouldn't be terribly hard).

In trying to find a more programmer friendly way of determining how many optical drives are in the system, I started looking at the udev source code.  I figured that if udev can determine how many optical drives exist, then eject should be able to do the same thing.  If you look at /lib/udev/rules.d/60-cdrom_id.rules, you will see that udev uses a program called cdrom_id to help it determine if a device is an optical drive.  It assumes the kernel assigned the CD-ROM a device name of either /dev/sr[0-9], /dev/hd[a-z] or /dev/xvcd* (apparently a Xen virtual drive).  Since the kernel supplies these names, they should be consistent across all recent distros.

The cdrom_id program uses uses an ioctl call in an attempt to access the drive's CD-ROM capabilities flags.  If the drive's capabilities flags are available, the drive is assumed to be an optical drive.  Unfortunately, the ioctl call requires an open file handle to the device.  Since this is a special character file, I'm not sure how much latency this open operation will introduce.  If you look in the cdrom_id source code, you will see that there is an intentional delay between attempts to obtain a file handle although I am not sure if it is necessary to repeat this delay in eject.  Overall, using this method to determine the number of optical drives is probably more maintainable but slower.

I'm currently looking into how udisks (derived from the old HAL code) determines if a device is an optical drive.  I still haven't located the code which does this.  If I can't turn up anything useful in udisks, I think I'll probably have exhausted my research options and will choose an ideal implementation.

Of course, the ideal implementation could use a series of different methods to determine if there is a single optical drive.  For example, first see if /dev/cdrom exists (for backward compatibility).  If /dev/cdrom does not exists, next see if /proc/sys/dev/cdrom/info exists.  If not, then use the udev method for optical drive detection.

Please note that I do not have a lot of experience modifying Linux utilities and the method used in Raseel's patch might be totally appropriate.  I would appreciate any thoughts from others who are more experienced in C, Ubuntu and/or Linux development.  At some point we should also contact Jeff Tranter upstream to see what he thinks of all this.