[gentoo-dev] John Jawed & Alex Tarkovsky's einput eclass

[gentoo-dev] John Jawed & Alex Tarkovsky's einput eclass

[Steve Long]

Hi,
 A link on bugzilla somehow led me (isn't the web wonderful ;) to this:
http://thread.gmane.org/gmane.linux.gentoo.devel/40596
 which appears (to a user) like a really good idea. There is a version still
at: http://jawed.name/dev/gentoo/einput.eclass 

 A search at: http://dir.gmane.org/gmane.linux.gentoo.devel
found only that thread, nor could I find anything on bugzilla. I was just
wondering what became of the idea?
 I appreciate that stable ebuilds aren't supposed to be interactive, but
this would be nice, eg for games, imo.

Regards,
steveL.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] John Jawed & Alex Tarkovsky's einput eclass

[Rémi Cardona]

Steve Long wrote:
> Hi,
>  A link on bugzilla somehow led me (isn't the web wonderful ;) to this:
> http://thread.gmane.org/gmane.linux.gentoo.devel/40596
>  which appears (to a user) like a really good idea. There is a version still
> at: http://jawed.name/dev/gentoo/einput.eclass 
> 
>  A search at: http://dir.gmane.org/gmane.linux.gentoo.devel
> found only that thread, nor could I find anything on bugzilla. I was just
> wondering what became of the idea?
>  I appreciate that stable ebuilds aren't supposed to be interactive, but
> this would be nice, eg for games, imo.

Could you list the packages which could use this? Because if only 3 pkgs
need it, it might not be worth the hassle to add it.

As you pointed it out, ebuilds should not be interactive. Imho, adding
an eclass to encourage it is counter-productive.

My 0.02€ :) Cheers

Rémi
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass

[Steve Long]

Rémi Cardona wrote:
> Could you list the packages which could use this? Because if only 3 pkgs
> need it, it might not be worth the hassle to add it.
/usr/portage $ grep -lR 'GAMES_CHECK_LICENSE="yes"' *games*|wc -l
40

I'm ofc not including fetch-restricted which also require interaction,
although that is standardised enough for a script to deal with[1]. Having
found this for games, I can deal with that too ofc, but I still think the
idea has merit. Consider, for example, a package with separate licenses for
parts, some of which the user may be happy with, others not. ATM the only
way to do that is with split ebuilds, aiui.

> As you pointed it out, ebuilds should not be interactive. Imho, adding
> an eclass to encourage it is counter-productive.
> 
Wow a humble gentoo dev! /me gets up off floor ;)

I understand that games are a `special case', but why not make it a
RESTRICT=interact which would automatically mean repoman would not allow
the package into stable, and admins could easily weed such packages out?
That way any category could use the same thing for packages with more
restrictive licenses. (I'm not suggesting this should be merged with
fetch-restricted as I accept that some stable Java packages have this set,
and there's zero benefit in changing them.)

So yeah I guess it's encouragement, but if the policy is such packages can
never hit stable, where's the harm? A user has to explicitly allow such a
package (or run unstable in which case they will be used to dealing with
glitches ;) and scripts can still avoid interactive packages. (And bear in
mind, it's not just uis we're talking about, but stuff like QA automation.)

My 2p.

[Apologies to older devs if this is a rehashed discussion.. Ignore Thread in
Kontact is fantastic ;p Besides, circumstances _change_. All it comes down
it to is: A) how useful is it? and B) how tough is it to implement? The
rest of it's horsesh1t imnsho. C) who will implement? is usually whichever
idiot came up with it ;) (see the original thread for an example of how
this list /could/ *work*.)]

[1] http://forums.gentoo.org/viewtopic-t-546828.html There'll be a new one
out in a few days with a really nice --sync interface; and no hanging on
game installs :D


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass

[Alex Tarkovsky]

On 7/7/07, Steve Long <slong@rathaus.eclipse.co.uk> wrote:
> I'm ofc not including fetch-restricted which also require interaction,
> although that is standardised enough for a script to deal with[1]. Having
> found this for games, I can deal with that too ofc, but I still think the

I'm not sure whether special license agreements are a legitimate case
for interactivity in some ebuilds, but I can tell you the einput
eclass was intended to be used only in pkg_config(), meaning the only
time the user would ever encounter einput is when they specifically
run "emerge --config foo" after installation, and even then it would
be only in a handful of ebuilds that actually need einput's services.
Burdening the user with the prospect of interactivity in any other
ebuild phase does seem to go against the Portage philosophy, so I feel
that einput.eclass is an edge case tool at best.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass

[Marius Mauch]

On Sun, 08 Jul 2007 04:53:40 +0100
Steve Long <slong@rathaus.eclipse.co.uk> wrote:

> I understand that games are a `special case', but why not make it a
> RESTRICT=interact which would automatically mean repoman would not
> allow the package into stable, and admins could easily weed such
> packages out? That way any category could use the same thing for
> packages with more restrictive licenses. (I'm not suggesting this
> should be merged with fetch-restricted as I accept that some stable
> Java packages have this set, and there's zero benefit in changing
> them.)

This isn't about stable or not stable, or about games being special. No
ebuild _should_ be interactive, period. However in some cases there is
no way to make it non-interactive, and the concentration of those cases
is particulary high in the games category (mainly because of a lack of
high quality OSS games).
Oh, and I've withdrawn the RESTRICT idea as there is a better/more
generic solution (not yet implemented though).

> So yeah I guess it's encouragement, but if the policy is such
> packages can never hit stable, where's the harm? A user has to
> explicitly allow such a package (or run unstable in which case they
> will be used to dealing with glitches ;) and scripts can still avoid
> interactive packages. (And bear in mind, it's not just uis we're
> talking about, but stuff like QA automation.)

Again, interactivity isn't a criterium for a package becoming stable or
not.

Marius

-- 
Marius Mauch <genone@gentoo.org>
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass

[Tiziano Müller]

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

Rémi Cardona schrieb:
> As you pointed it out, ebuilds should not be interactive. Imho, adding
> an eclass to encourage it is counter-productive.

While that's true, there might be a use case in pkg_config.
For example postgresql which needs quiet a few parameters to initialize
the first database cluster. If we could present the user a couple of
options in a list where he can just select the one he wants.

Cheers,
Tiziano



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

[gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass

[Tiziano Müller]

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

Steve Long schrieb:
> Hi,
>  A link on bugzilla somehow led me (isn't the web wonderful ;) to this:
> http://thread.gmane.org/gmane.linux.gentoo.devel/40596
>  which appears (to a user) like a really good idea. There is a version still
> at: http://jawed.name/dev/gentoo/einput.eclass 
> 

A newer version of the mentioned eclass is available here:
http://overlays.gentoo.org/proj/postgresql/browser/testing/eclass/einput.eclass

Cheers,
Tiziano


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

[gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass

[Tiziano Müller]

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

Sorry for the "atomic" posts, I should rather first think before hitting
the send button :-\

The problem with the proposed einput.eclass is that the user has to use
the commandline for that, which is fine for a lot of people.

At the moment I'd rather like to see a proposal for an "API" (together
with the use cases it tries to solve) and leave the implementation
aside. Hoping that we get a solution which doesn't depend on the
commandline but can also be used with a GUI, a braille-display, etc.

Regards,
Tiziano






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

Re: [gentoo-dev] Re: John Jawed & Alex Tarkovsky's einput eclass

[Rémi Cardona]

Tiziano Müller wrote:
> Sorry for the "atomic" posts, I should rather first think before hitting
> the send button :-\
> 
> The problem with the proposed einput.eclass is that the user has to use
> the commandline for that, which is fine for a lot of people.
> 
> At the moment I'd rather like to see a proposal for an "API" (together
> with the use cases it tries to solve) and leave the implementation
> aside. Hoping that we get a solution which doesn't depend on the
> commandline but can also be used with a GUI, a braille-display, etc.

What would you think of a zenity-like API (it's a gnome utility) ? I
think it's pretty much like dialog, there could be a way to write a
common script for both based on a set of use cases.

I think debian *gasp* has something like that. Could be worth taking a
look at what they did.

Cheers,

Rémi
-- 
gentoo-dev@gentoo.org mailing list