[gentoo-dev] Moving virtual/eject to new-style virtual

[gentoo-dev] Moving virtual/eject to new-style virtual

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 691 bytes --]

So, right now virtual/eject is the old-style virtual that gets listed in 
virtuals file in the profiles, defaulting to sys-apps/eject that is Linux 
only.

I would like to move it to a new-style virtual to make it simpler to handlef 
or other platforms, having the deps this way:

|| ( kernel_linux? ( sys-apps/eject ) sys-block/unieject kernel_FreeBSD? ( 
sys-apps/eject-bsd ) )

this way when used with a kernel different by Linux it defaults to unieject 
(my reimplementation) that using libcdio would be simpler to port.

Thoughts?

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Moving virtual/eject to new-style virtual

[Harald van Dijk]

On Tue, May 23, 2006 at 12:38:55PM +0200, Diego 'Flameeyes' Pettenò wrote:
> So, right now virtual/eject is the old-style virtual that gets listed in 
> virtuals file in the profiles, defaulting to sys-apps/eject that is Linux 
> only.
> 
> I would like to move it to a new-style virtual to make it simpler to handlef 
> or other platforms, having the deps this way:
> 
> || ( kernel_linux? ( sys-apps/eject ) sys-block/unieject kernel_FreeBSD? ( 
> sys-apps/eject-bsd ) )
> 
> this way when used with a kernel different by Linux it defaults to unieject 
> (my reimplementation) that using libcdio would be simpler to port.
> 
> Thoughts?

(I've been meaning to ask this for a while, it's not specific to
virtual/eject.)

How does it help? New-style virtuals have several disadvantages, and the
usual advantages of new-style virtuals don't apply here. If it actually
provides real benefits, then no objections from me, but how is this
easier to maintain than a "virtual/eject sys-block/unieject" entry in
the default-bsd profile?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving virtual/eject to new-style virtual

[Diego 'Flameeyes' Pettenò]

[-- Attachment #1: Type: text/plain, Size: 1358 bytes --]

On Tuesday 23 May 2006 13:25, Harald van Dijk wrote:
> How does it help? New-style virtuals have several disadvantages, and the
> usual advantages of new-style virtuals don't apply here. If it actually
> provides real benefits, then no objections from me, but how is this
> easier to maintain than a "virtual/eject sys-block/unieject" entry in
> the default-bsd profile?
I should have explained what my whole plan was, probably :)

Currently there are things provided by sys-apps/eject that are not available 
on either unieject or eject-bsd.. the final idea was, from my part, to 
identify those features in three versions "0a 0b 0c" (the 0 version is to 
avoid collisions between virtual/eject and sys-apps/eject binpks).

0a would be simply the basic eject command, what it is now.
0b would be basic eject + --trayclose (needed by rip for instance)
0c would be ability to eject usb/scsi devices.

The first case is the dependency as it is now, the second is eject or 
unieject, the third would be just eject and thus not keyworded ~x86-fbsd at 
all.

When I'll be able to provide 0c features in unieject, I'd add that to 0c.

The need for usb/scsi eject is given by libgpod and related :)

-- 
Diego "Flameeyes" Pettenò - http://farragut.flameeyes.is-a-geek.org/
Gentoo/Alt lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Moving virtual/eject to new-style virtual

[Harald van Dijk]

On Tue, May 23, 2006 at 01:35:49PM +0200, Diego 'Flameeyes' Pettenò wrote:
> On Tuesday 23 May 2006 13:25, Harald van Dijk wrote:
> > How does it help? New-style virtuals have several disadvantages, and the
> > usual advantages of new-style virtuals don't apply here. If it actually
> > provides real benefits, then no objections from me, but how is this
> > easier to maintain than a "virtual/eject sys-block/unieject" entry in
> > the default-bsd profile?
> I should have explained what my whole plan was, probably :)
> 
> Currently there are things provided by sys-apps/eject that are not available 
> on either unieject or eject-bsd.. the final idea was, from my part, to 
> identify those features in three versions "0a 0b 0c" (the 0 version is to 
> avoid collisions between virtual/eject and sys-apps/eject binpks).
> 
> 0a would be simply the basic eject command, what it is now.
> 0b would be basic eject + --trayclose (needed by rip for instance)
> 0c would be ability to eject usb/scsi devices.
> 
> The first case is the dependency as it is now, the second is eject or 
> unieject, the third would be just eject and thus not keyworded ~x86-fbsd at 
> all.
> 
> When I'll be able to provide 0c features in unieject, I'd add that to 0c.
> 
> The need for usb/scsi eject is given by libgpod and related :)

Thanks for the explanation. It seems sane enough, at least to me, now :)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving virtual/eject to new-style virtual

[Ned Ludd]

On Tue, 2006-05-23 at 12:38 +0200, Diego 'Flameeyes' Pettenò wrote:
> So, right now virtual/eject is the old-style virtual that gets listed in 
> virtuals file in the profiles, defaulting to sys-apps/eject that is Linux 
> only.

Please refrain from adding any new(bad) style virtuals till
http://bugs.gentoo.org/show_bug.cgi?id=133908
is resolved.


-- 
Ned Ludd <solar@gentoo.org>
Gentoo Linux

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving virtual/eject to new-style virtual

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 462 bytes --]

Ned Ludd wrote:
> On Tue, 2006-05-23 at 12:38 +0200, Diego 'Flameeyes' Pettenò wrote:
>> So, right now virtual/eject is the old-style virtual that gets listed in 
>> virtuals file in the profiles, defaulting to sys-apps/eject that is Linux 
>> only.
> 
> Please refrain from adding any new(bad) style virtuals till
> http://bugs.gentoo.org/show_bug.cgi?id=133908

At least, ones with identical versioning to a non-virtual package.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Moving virtual/eject to new-style virtual

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Harald van Dijk wrote:
> How does it help? New-style virtuals have several disadvantages, and the
> usual advantages of new-style virtuals don't apply here. If it actually
> provides real benefits, then no objections from me, but how is this
> easier to maintain than a "virtual/eject sys-block/unieject" entry in
> the default-bsd profile?

Could you expand on the disadvantages?

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Moving virtual/eject to new-style virtual

[Harald van Dijk]

On Tue, May 23, 2006 at 07:12:53AM -0700, Donnie Berkholz wrote:
> Harald van Dijk wrote:
> > How does it help? New-style virtuals have several disadvantages, and the
> > usual advantages of new-style virtuals don't apply here. If it actually
> > provides real benefits, then no objections from me, but how is this
> > easier to maintain than a "virtual/eject sys-block/unieject" entry in
> > the default-bsd profile?
> 
> Could you expand on the disadvantages?

New-style virtuals aren't automatically provided when the relevant
packages get installed, can't block themselves when only one may be
installed at a time, can't be provided from an ebuild in an overlay
without adding a virtual ebuild too, which must be kept in sync with the
one in gentoo-x86, and more simply are ugly in emerge --pretend output.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Moving virtual/eject to new-style virtual

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 300 bytes --]

Harald van Dijk wrote:
> can't block themselves when only one may be
> installed at a time,

This is the one that really annoys me. New-style virtuals are supposed
to make things so easy, but you end up having a ton of crap added to
each provider to block all the others.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]