| 1 |
On Tuesday 23 May 2006 13:25, Harald van Dijk wrote: |
| 2 |
> How does it help? New-style virtuals have several disadvantages, and the |
| 3 |
> usual advantages of new-style virtuals don't apply here. If it actually |
| 4 |
> provides real benefits, then no objections from me, but how is this |
| 5 |
> easier to maintain than a "virtual/eject sys-block/unieject" entry in |
| 6 |
> the default-bsd profile? |
| 7 |
I should have explained what my whole plan was, probably :) |
| 8 |
|
| 9 |
Currently there are things provided by sys-apps/eject that are not available |
| 10 |
on either unieject or eject-bsd.. the final idea was, from my part, to |
| 11 |
identify those features in three versions "0a 0b 0c" (the 0 version is to |
| 12 |
avoid collisions between virtual/eject and sys-apps/eject binpks). |
| 13 |
|
| 14 |
0a would be simply the basic eject command, what it is now. |
| 15 |
0b would be basic eject + --trayclose (needed by rip for instance) |
| 16 |
0c would be ability to eject usb/scsi devices. |
| 17 |
|
| 18 |
The first case is the dependency as it is now, the second is eject or |
| 19 |
unieject, the third would be just eject and thus not keyworded ~x86-fbsd at |
| 20 |
all. |
| 21 |
|
| 22 |
When I'll be able to provide 0c features in unieject, I'd add that to 0c. |
| 23 |
|
| 24 |
The need for usb/scsi eject is given by libgpod and related :) |
| 25 |
|
| 26 |
-- |
| 27 |
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/ |
| 28 |
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE |
Archives