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