Gentoo Archives: gentoo-dev

From: "Harald van Dijk" <truedfx@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Moving virtual/eject to new-style virtual
Date: Tue, 23 May 2006 11:54:12
Message-Id: 20060523115212.GA8696@gentoo.org
In Reply to: Re: [gentoo-dev] Moving virtual/eject to new-style virtual by "Diego 'Flameeyes' Pettenò"
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