Re: [gentoo-dev] Re: Interaction in ebuilds - bad idea?

[Chris Gianelloni]

On Fri, 2004-04-30 at 17:39, Stuart Herbert wrote:
> For example, if we absolutely *have* to ask the user for some information for
> an ebuild - if there's no way to script it (and I think there is) - let's
> make Portage ask all the questions *before* downloading and compiling
> anything.  It makes sense to ask all the questions up-front, so that the user
> doesn't constantly have to check his 'emerge -u world' to see if it has
> stopped to ask a question.

This would be perfect for ebuilds which we are required to ask the user
to explicitly accept the license.  This mechanism would be able to fit
both the needs for interactivity and the needs of the ACCEPT_LICENSE
variable.

> Imagine running, for an example, 'emerge -u world'.  Once Portage has
> calculated the dependencies, it could call a function (let's call it
> pkg_askuser) in each ebuild to gather further information.  pkg_askuser would
> need some library functions to call, so that we can standardise the user's
> experience.  Portage would have to cache the information gathered by
> pkg_askuser, and then it could continue with running each ebuild in turn
> exactly as it currently does.  Each ebuild would have access to the cache
> (how doesn't matter yet), so that it can use the right database server, the
> right user and password, or whatever that information needs to be.
>
> The cache itself can be reused in future - so that the user doesn't have to
> type in the same information the next time he does an 'emerge -u world'.  We
> could store the cache inside the profile, for example.  Just as we have a
> use.desc file to explain what each USE flag does, we could add a cache.desc
> file to explain what each value in the cache is for.

I like it.  I can already think of one usable variable, ACCEPT_LICENCE,
which is used by the games team (anyone else?) to force a user to accept
a license.  Currently, this breaks the non-interactivity of portage,
since there is not any code in portage itself for handling this.

> We could even provide a tool to edit the cache - and hey presto - without that
> much effort we've just made ebuilds a lot smarter, and Gentoo an even better
> platform.

> If the Portage team could add the pkg_askuser() and the cache, then any ebuild
> maintainer could start taking advantage very quickly.  Anyone from the
> Portage team care to comment on this idea?

I think this is a great idea.  I also think that the portage devs are
pretty busy, so let's all hope that they can get some much-needed help
to get this implemented.

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?