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

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

[Eldad Zack]

On Fri, 2004-04-30 at 00:04, Ajai Khattri wrote:
> Let's say I have an ebuild that uses mysql. Somewhere is a place for you
> to specify the host, db name, username and password for MySQL during the
> build process. If I wanted to ask the user that info, then what is the
> standard way of doing that? (Or am I using the wrong paradigm?).

The best way is to allow run-time configuration in /etc files.

If you MUST specify these details at build time (and without knowing
exactly what is the application in question) - well, it's a braindamaged
application. IMHO, this should go in a portage enviornmental and the
ebuild should never be interactive.


Eldad


--
gentoo-dev@gentoo.org mailing list

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

[Ajai Khattri]

Let's say I have an ebuild that uses mysql. Somewhere is a place for you
to specify the host, db name, username and password for MySQL during the
build process. If I wanted to ask the user that info, then what is the
standard way of doing that? (Or am I using the wrong paradigm?).

(Yes, Im working on a patch that uses mysql).


-- 
Aj.
Sys. Admin / Developer

--
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

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

On Thursday 29 April 2004 22:04, Ajai Khattri wrote:
> Let's say I have an ebuild that uses mysql. Somewhere is a place for you
> to specify the host, db name, username and password for MySQL during the
> build process. If I wanted to ask the user that info, then what is the
> standard way of doing that? (Or am I using the wrong paradigm?).
>
> (Yes, Im working on a patch that uses mysql).

Right now, there's no standard way.  Most ebuilds assume that you're accessing 
mysql using 'mysql -u root' on the localhost.  I've seen at least one which 
prompts for these details - and makes a complete pigs ear of it.

There's a whole heap of work that we need to do to improve the way ebuilds 
work with databases.  It's something I intend to do once webapp-config is 
bedded in and stable for most people, because it's desperately needed for 
many web-based applications.

Here's the points I want to tackle include:

* standard way for ebuilds to interact with database servers locally
* support for ebuilds to work with a remote database server
* standard way for ebuilds to install new databases
  - naming schemes for databases
  - naming schemes for users that apps use
* a standard way to automate upgrading databases when we upgrade apps
  - auto-generation of SQL upgrade scripts
    (we can't rely on UPSTREAM to provide them)
* a standard way to automate removing databases when we remove apps
  - what do we remove
  - when do we remove it
* hooks so that we can add new databases to backup schemes automatically
  - oh the fun ;-)

I think we need to put a design down as a GLEP, as introducing the tool or 
tools to do all of this will impact users and devs alike.

Thoughts, comments?  Anyone interested in helping out on this?

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Missed the php|cruise?             http://dev.gentoo.org/~stuart/cruise-2004/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

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

[Ajai Khattri]

On Fri, 30 Apr 2004, Eldad Zack wrote:

> The best way is to allow run-time configuration in /etc files.

I had a feeling that would be the answer ;-)

So I have some more work to do I guess.


-- 
Aj.
Sys. Admin / Developer

--
gentoo-dev@gentoo.org mailing list

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

[Nick Rout]

On Thu, 29 Apr 2004 17:32:04 -0400 (EDT)
Ajai Khattri <ajai@bway.net> wrote:

> On Fri, 30 Apr 2004, Eldad Zack wrote:
> 
> > The best way is to allow run-time configuration in /etc files.
> 
> I had a feeling that would be the answer ;-)
> 
> So I have some more work to do I guess.
> 

some ebuilds tell you to run a configuration script after the ebuild
completes (although often this disappears in the other cruft that emerge
throws past you)

something like 

ebuild /usr/portage/path-to/app/app-1.0.ebuild configure

(although thats probably not the wording. I cannot be darned finding a
live example now.)


> 
> -- 
> Aj.
> Sys. Admin / Developer
> 
> --
> gentoo-dev@gentoo.org mailing list

-- 
Nick Rout <nick@rout.co.nz>


--
gentoo-dev@gentoo.org mailing list

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

[Tom Wesley]

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

On Thu, 2004-04-29 at 22:36, Nick Rout wrote:
> On Thu, 29 Apr 2004 17:32:04 -0400 (EDT)
> Ajai Khattri <ajai@bway.net> wrote:
> 
> > On Fri, 30 Apr 2004, Eldad Zack wrote:
> > 
> > > The best way is to allow run-time configuration in /etc files.
> > 
> > I had a feeling that would be the answer ;-)
> > 
> > So I have some more work to do I guess.
> > 
> 
> some ebuilds tell you to run a configuration script after the ebuild
> completes (although often this disappears in the other cruft that emerge
> throws past you)
> 
> something like 
> 
> ebuild /usr/portage/path-to/app/app-1.0.ebuild configure
> 
> (although thats probably not the wording. I cannot be darned finding a
> live example now.)
> 

Since I have just 10 minutes ago emerged it, freenet does this.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Andy Arbon]

Although now you mention it, doesn't Freenet's ebuild tell you to run a
file that doesn't exist? If I remember rightly, the path it gives you
isn't the correct one to the ebuild..

Or am I talking rubbish?

Andy

> > some ebuilds tell you to run a configuration script after the ebuild
> > completes (although often this disappears in the other cruft that emerge
> > throws past you)
> > 
> > something like 
> > 
> > ebuild /usr/portage/path-to/app/app-1.0.ebuild configure
> > 
> > (although thats probably not the wording. I cannot be darned finding a
> > live example now.)
> > 
> 
> Since I have just 10 minutes ago emerged it, freenet does this.
> 


--
gentoo-dev@gentoo.org mailing list

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

[Ryan Phillips]

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

* Stuart Herbert <stuart@gentoo.org> [2004-04-29 14:30]:
> On Thursday 29 April 2004 22:04, Ajai Khattri wrote:
> 
> Here's the points I want to tackle include:
> 
> * standard way for ebuilds to interact with database servers locally
> * support for ebuilds to work with a remote database server
> * standard way for ebuilds to install new databases
>   - naming schemes for databases
>   - naming schemes for users that apps use
> * a standard way to automate upgrading databases when we upgrade apps
>   - auto-generation of SQL upgrade scripts
>     (we can't rely on UPSTREAM to provide them)
> * a standard way to automate removing databases when we remove apps
>   - what do we remove
>   - when do we remove it
> * hooks so that we can add new databases to backup schemes automatically
>   - oh the fun ;-)
> 
> I think we need to put a design down as a GLEP, as introducing the tool or 
> tools to do all of this will impact users and devs alike.
> 
> Thoughts, comments?  Anyone interested in helping out on this?
> 
> Best regards,
> Stu

I think this is a really good idea.  The ebuild config mechanism is
not all that smart.  Since, there is work on an installer there should
be some mechanism for the installer to query an "install specification
file" per package.  Something like an installshield script, but it
needs to export configuration items (ie: parameters, possible values,
etc).  The interface should be generic enough so that any type of
configuration utility (GUI, console, or non-interactive) can run the
configuration.

Depending on the time frame... I may be able to help out on this.
Graduation from college is at the end of this year (I hope :).

-Ryan

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

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

[Stuart Herbert]

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

On Friday 30 April 2004 22:06, Ryan Phillips wrote:
> I think this is a really good idea.  The ebuild config mechanism is
> not all that smart.  

Let's try and make it smarter.

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.

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.

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.

> Since, there is work on an installer there should 
> be some mechanism for the installer to query an "install specification
> file" per package.  

Isn't the installer's role to perform that initial install onto virgin 
hardware?  Will the installer really play a role in the day to day 
maintenance of a Gentoo box?

> Something like an installshield script, 

urgh, please no ;-)

Besides, we already have something like that - the ebuilds themselves.

> but it  
> needs to export configuration items (ie: parameters, possible values,
> etc).  The interface should be generic enough so that any type of
> configuration utility (GUI, console, or non-interactive) can run the
> configuration.

dialog and xdialog would be a good starting point.  Although personally I'd 
throw dialog out of the window, and use lxdialog from the kernel instead ;-)

> Depending on the time frame... I may be able to help out on this.
> Graduation from college is at the end of this year (I hope :).

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?

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Missed the php|cruise?             http://dev.gentoo.org/~stuart/cruise-2004/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

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

[Marius Mauch]

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

On 04/30/04  Stuart Herbert wrote:

> On Friday 30 April 2004 22:06, Ryan Phillips wrote:
> > I think this is a really good idea.  The ebuild config mechanism is
> > not all that smart.  
> 
> Let's try and make it smarter.
> 
> 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.
> 
> 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.

I don't like that idea, portage shouldn't be interactive by default. Use
pkg_setup() and tell the user to set the required values via the
environment or with a tool, let's call it gentoo-db-config for now.
That's the standard way to do such things (java-config, gcc-config) and
I don't see why databases should be an exception.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

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

[Stuart Herbert]

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

On Friday 30 April 2004 22:53, Marius Mauch wrote:
> I don't like that idea, portage shouldn't be interactive by default. 

Hrm.  It would only have to be interactive the first time - when it has 
questions that it doesn't have answers to.  And it asks all of those 
questions up-front - when it has the user's attention.

It's no different in principle to the way that a windows-based installer asks 
you all the questions before installing your files.  It's a 
human-computer-interaction model that most people understand, and are 
comfortable with.

> Use pkg_setup() 

... and output a message that the user probably won't read, because it appears 
two hours into an 'emerge -u world' and has long gone from the terminal's 
screen buffer by the time the user returns.  

I think asking the user *before* the emerge -u world begins is a lot 
friendlier myself.

> and tell the user to set the required values via the 
> environment or with a tool, let's call it gentoo-db-config for now.

Sounds like the 'cache editor' that I mentioned in my original post.

> That's the standard way to do such things (java-config, gcc-config) and
> I don't see why databases should be an exception.

These tools don't influence ebuilds at all.

Although it might benefit working with databases, my idea about improving 
Portage is a more general idea.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Missed the php|cruise?             http://dev.gentoo.org/~stuart/cruise-2004/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

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

[Brandon Hale]

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

On Fri, 2004-04-30 at 23:28 +0100, Stuart Herbert wrote:
> On Friday 30 April 2004 22:53, Marius Mauch wrote:
> > I don't like that idea, portage shouldn't be interactive by default. 
> 
> Hrm.  It would only have to be interactive the first time - when it has 
> questions that it doesn't have answers to.  And it asks all of those 
> questions up-front - when it has the user's attention.
> 
> It's no different in principle to the way that a windows-based installer asks 
> you all the questions before installing your files.  It's a 
> human-computer-interaction model that most people understand, and are 
> comfortable with.

Debian already does what you are talking about, with gtk and ncurses
frontends being optional. Questions have priority, you can set what
questions you want to see and which to allow defaults on, eg ask
questions with greater than medium importance. It's also possible to
re-run the questionnaires per package. This is how they configure XFree
drivers + modelines, ask permission to setuid on certain bins, etc. I
don't necessarily support this idea, just giving a possible source of
inspiration (or even what not to do, as the case may be).

> > Use pkg_setup() 
> 
> ... and output a message that the user probably won't read, because it appears 
> two hours into an 'emerge -u world' and has long gone from the terminal's 
> screen buffer by the time the user returns.  
> 
> I think asking the user *before* the emerge -u world begins is a lot 
> friendlier myself.
> 
> > and tell the user to set the required values via the 
> > environment or with a tool, let's call it gentoo-db-config for now.
> 
> Sounds like the 'cache editor' that I mentioned in my original post.
> 
> > That's the standard way to do such things (java-config, gcc-config) and
> > I don't see why databases should be an exception.
> 
> These tools don't influence ebuilds at all.
> 
> Although it might benefit working with databases, my idea about improving 
> Portage is a more general idea.
> 
> Best regards,
> Stu
> -- 
> Stuart Herbert                                              stuart@gentoo.org
> Gentoo Developer                                       http://www.gentoo.org/
> Missed the php|cruise?             http://dev.gentoo.org/~stuart/cruise-2004/
> 
> GnuPG key id# F9AFC57C available from http://pgp.mit.edu
> Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
> --

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Grant Goodyear]

On Fri, Apr 30, 2004 at 11:28:07PM +0100, Stuart Herbert wrote:
> Hrm.  It would only have to be interactive the first time - when it has 
> questions that it doesn't have answers to.  And it asks all of those 
> questions up-front - when it has the user's attention.
> 
> It's no different in principle to the way that a windows-based installer asks 
> you all the questions before installing your files.  It's a 
> human-computer-interaction model that most people understand, and are 
> comfortable with.

We have always strenuously resisted making ebuilds interactive because
interactive ebuilds are impossible (or at least very hard) to script.
-- 
g2boojum@gentoo.org

--
gentoo-dev@gentoo.org mailing list

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

[Aiko Barz]

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

On Fri, Apr 30, 2004 at 09:36:56AM +1200, Nick Rout wrote:
> 
> On Thu, 29 Apr 2004 17:32:04 -0400 (EDT)
> Ajai Khattri <ajai@bway.net> wrote:
> 
> > On Fri, 30 Apr 2004, Eldad Zack wrote:
> > 
> > > The best way is to allow run-time configuration in /etc files.

I don't like the idea. I know it from Debian. For Debian it's ok, but
gentoo is different.

> some ebuilds tell you to run a configuration script after the ebuild
> completes (although often this disappears in the other cruft that emerge
> throws past you)

In my opinion, that's the best argument for using a run-time
configuration. 
But even this wouldn't work out. I've got a celeron 333MHz, which is
running gentoo. I don't want to look after my machine every hour to
receive a new "run-time configuration"-instruction. ;)
So you would need at least some kind of "default-choice" for people,
that do not want to be asked.

I would prefer an update logfile, which can be viewed and deleted with
etc-update. This log could keep all hints, which have been made during
the last update.

Bis denne,
        Aiko

-- 
  .~.	 Aiko Barz
  /v\ 	 
 // \\	 Mail: aiko@chroot.de
/( _ )\  Web:  http://www.chroot.de
 ^^ ^^   PGP:  http://www.chroot.de/index.php?navi=GnuPG


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

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

[Marius Mauch]

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

On 04/30/04  Stuart Herbert wrote:

> It's no different in principle to the way that a windows-based >
> installer asks you all the questions before installing your files.  >
> It's a human-computer-interaction model that most people understand, >
> and are comfortable with.

And next we introduce "Next" buttons?

> > Use pkg_setup() 
> 
> ... and output a message that the user probably won't read, because it
> appears two hours into an 'emerge -u world' and has long gone from the
> terminal's screen buffer by the time the user returns.  

Hmm, I forgot that part in my mail: We can talk about collecting all
to-be-executed pkg_setup functions and execute them before any
src_unpack/src_compile function or make a new one that's executed then,
but I won't support any interactive function in ebuilds that will be
executed by default (read: if the user calls it explicitly I'm ok with
it).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

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

[Grant Goodyear]

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

On Sat, May 01, 2004 at 12:40:55AM +0100, Stuart Herbert wrote:
> > We have always strenuously resisted making ebuilds interactive because
> > interactive ebuilds are impossible (or at least very hard) to script.
> 
> Why?
> 
> Interactive install scripts are older than any surviving Linux distribution.
> 
> I think the easiest way to put this case forward is going to be a patch 
> demonstrating it actually working.

Oh, dear.  I'm afraid I wasn't very clear about what I meant.  I didn't
mean that it's hard to write an interactive script, of course that's
reasonably straightforward.  What I was trying, rather poorly, to say
was that one of the long-time tenets of Gentoo has always been that it
should be possible for people to write simple scripts to _install_
ebuilds.  For example, somebody should be able to write a poor-man's
"kickstart" that would build and install a desired set of ebuilds,
perhaps with customized USE flags.  Or use cfengine to install a
particular well-tested ebuild on one hundred machines.  To the best of
my knowledge having interactive ebuilds would make _that_ sort of
scripting much more difficult.

Does that make more sense?

Best,
g2boojum
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

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

[Stuart Herbert]

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

On Saturday 01 May 2004 01:13, Grant Goodyear wrote:
> Oh, dear.  I'm afraid I wasn't very clear about what I meant.  I didn't
> mean that it's hard to write an interactive script, of course that's
> reasonably straightforward.  What I was trying, rather poorly, to say
> was that one of the long-time tenets of Gentoo has always been that it
> should be possible for people to write simple scripts to _install_
> ebuilds.  For example, somebody should be able to write a poor-man's
> "kickstart" that would build and install a desired set of ebuilds,
> perhaps with customized USE flags.  Or use cfengine to install a
> particular well-tested ebuild on one hundred machines.  To the best of
> my knowledge having interactive ebuilds would make _that_ sort of
> scripting much more difficult.
>
> Does that make more sense?

Yup.

Like I said, it would only have to ask for information that wasn't available 
from the cache of answers.  Provided there was a tool to pre-edit the cache - 
something I suggested earlier - then your scenarios would work.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Missed the php|cruise?             http://dev.gentoo.org/~stuart/cruise-2004/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

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

[Jeremy Maitin-Shepard]

Stuart Herbert <stuart@gentoo.org> writes:

> Like I said, it would only have to ask for information that wasn't available 
> from the cache of answers.  Provided there was a tool to pre-edit the cache - 
> something I suggested earlier - then your scenarios would work.

I would agree with Marius in saying that ebuilds should not by default
be interactive.  Furthermore, I dislike the idea of a cache because it
makes the configuration data more obscure to the user.  Provided that
the generic facility of package-specific environment variables in the
same style as package-specific USE flags is added to Portage,
environment variables specified in /etc/portage/whatever are sufficient
for specifying the configuration.

It would be useful for ebuilds to be able to specify a check function
which runs prior to merging any packages (possibly based on an option to
emerge).  This would allow the ebuild to fail immediately, informing the
user of what is required, if a valid configuration is not specified in
environment variables.  Furthermore, I would like to see immediate
failure if a license must be explicitly accepted and is not in
ACCEPT_LICENSES; I find the interactive prompting to accept licenses
problematic for the same reasons as interactive configuration prompting
is problematic.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

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

[Chris Bainbridge]

On Thursday 29 April 2004 22:01, Eldad Zack wrote:
> On Fri, 2004-04-30 at 00:04, Ajai Khattri wrote:
> > Let's say I have an ebuild that uses mysql. Somewhere is a place for you
> > to specify the host, db name, username and password for MySQL during the
> > build process. If I wanted to ask the user that info, then what is the
> > standard way of doing that? (Or am I using the wrong paradigm?).
>
> The best way is to allow run-time configuration in /etc files.
>
> If you MUST specify these details at build time (and without knowing
> exactly what is the application in question) - well, it's a braindamaged
> application. IMHO, this should go in a portage enviornmental and the
> ebuild should never be interactive.

Sometimes this just isn't possible. I had one application which required 
src_uri files to be retrieved from a password protected ftp server. Portage 
should be powerful enough to do stuff like that without hardcoding usernames 
and passwords in the ebuild.

--
gentoo-dev@gentoo.org mailing list

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

[Jason Stubbs]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 01 May 2004 12:36, Jeremy Maitin-Shepard wrote:
> Furthermore, I would like to see immediate failure if a license must be 
> explicitly accepted and is not in ACCEPT_LICENSES; I find the interactive 
> prompting to accept licenses problematic for the same reasons as interactive 
> configuration prompting is problematic.   

When I get around to implementing ACCEPT_LICENSE support, it will function 
similarly to blockers. When using the -p option, all licenses requiring 
acceptance will be shown. When not using the -p option, the first license 
that hasn't been accepted will cause emerge to stop during the dependency 
calculation phase.

Regards,
Jason Stubbs
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQJOgt1oikN4/5jfsAQJlvQP9GHZ3R0WpdfovR83JBAW+/jbocZtpnAIK
ZuMxy6GeQyLUePN4IhJh59m9J6xMk4dsXRpVRuuz/bbZQ0nKmsPuIyf5AXfBx3zZ
C+f+4rCFE8jIPAIi6K7k7MiIllJvwBfnapPzNKT53nJrN/oA4FX9iiWMsZ9Si+89
qQpnqZDp5QU=
=CKgI
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

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

[Wazow]

Brandon Hale <tseng@gentoo.org> writes:

> Debian already does what you are talking about, with gtk and ncurses
> frontends being optional. 

Except that Debian asks all the questions in the end. While in the end
is better than scattered around in the whole emerge world log (what
gentoo does now in a way), asking them up front would be a whole lot
better. I only wonder if all relevant questions can be asked before the
package is installed.

Andrzej


--
gentoo-dev@gentoo.org mailing list

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

[Paul de Vrieze]

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

On Saturday 01 May 2004 02:33, Stuart Herbert wrote:
> On Saturday 01 May 2004 01:13, Grant Goodyear wrote:
> > Oh, dear.  I'm afraid I wasn't very clear about what I meant.  I didn't
> > mean that it's hard to write an interactive script, of course that's
> > reasonably straightforward.  What I was trying, rather poorly, to say
> > was that one of the long-time tenets of Gentoo has always been that it
> > should be possible for people to write simple scripts to _install_
> > ebuilds.  For example, somebody should be able to write a poor-man's
> > "kickstart" that would build and install a desired set of ebuilds,
> > perhaps with customized USE flags.  Or use cfengine to install a
> > particular well-tested ebuild on one hundred machines.  To the best of
> > my knowledge having interactive ebuilds would make _that_ sort of
> > scripting much more difficult.
> >
> > Does that make more sense?
>
> Yup.
>
> Like I said, it would only have to ask for information that wasn't
> available from the cache of answers.  Provided there was a tool to pre-edit
> the cache - something I suggested earlier - then your scenarios would work.

I agree with such a setup. Have a way in which - optionally - the ebuild can 
be preconfigured. This configuration would need to be selfcontained in such a 
way that the configuration files can be copied and created at any time. 

Paul

ps. Besides this I feel the need to allow per-ebuild descriptions on useflags. 
Those descriptions would describe what the consequences of the useflags are. 
Like for subversion the berkdb useflag signifies whether the server part gets 
build (because berkdb is needed for that), it would be very usefull to have 
some easilly accessible description for it.

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

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

[Wazow]

Jeremy Maitin-Shepard <jbms@gentoo.org> writes:
> Stuart Herbert <stuart@gentoo.org> writes:
>
>> Like I said, it would only have to ask for information that wasn't available 
>> from the cache of answers.  Provided there was a tool to pre-edit the cache - 
>> something I suggested earlier - then your scenarios would work.
>
> I would agree with Marius in saying that ebuilds should not by default

> I dislike the idea of a cache because it makes the configuration data
> more obscure to the user.  

In fact the idea of cache is extremely bad. It would create something
like global registry of settings which will overwrite my grand setup at
every emerge. No thank you.

I think I like non-interactive emerge a lot, but I would like it to
present all requests for configurations etc in more coherent way. For
instance they should be gathered in a single log or, even better, send
to the end of the whole emerge output (once for all packages). Current
distribution (of often crucial information) across heaps of messages
does not make much sense. 

Actually I do not understand why some applications can't live without
interactive setup. Can anybody explain it better?

Andrzej


--
gentoo-dev@gentoo.org mailing list

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

[Stuart Herbert]

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

On Saturday 01 May 2004 17:03, Wazow wrote:
> Actually I do not understand why some applications can't live without
> interactive setup. Can anybody explain it better?
>
> Andrzej

The scenario that interests me is where you have multiple sites hosted on a 
single box.  This requires support for installing multiple copies of the same 
application (which is what webapp-config does for us) - and each of these 
copies needs to use a different database and/or different table names.

At the moment, we deal with this by having pkg_postinst() output instructions 
as to how to setup the database by hand.  If the ebuild knew which database 
to manipulate, we'd be one step closer to automating this process.

In this scenario, ideas like adding new variables to make.conf simply do not 
scale.  What we'll probably end up doing is making it possible to query a 
per-vhost set of configuration values through the vhost-config tool, and 
providing a static default for desktop/single-host servers.

Best regards,
Stu
-- 
Stuart Herbert                                              stuart@gentoo.org
Gentoo Developer                                       http://www.gentoo.org/
Missed the php|cruise?             http://dev.gentoo.org/~stuart/cruise-2004/

GnuPG key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--

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

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

[Chris Gianelloni]

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

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?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Chris Gianelloni]

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

On Sat, 2004-05-01 at 09:05, Jason Stubbs wrote:
> When I get around to implementing ACCEPT_LICENSE support, it will function 
> similarly to blockers. When using the -p option, all licenses requiring 
> acceptance will be shown. When not using the -p option, the first license 
> that hasn't been accepted will cause emerge to stop during the dependency 
> calculation phase.

MMMMM... Warm and squishy goodness...

This sounds perfect for the license acceptance.  Definitely keep me
informed on the progress, as this is definitely a hot item on my plate
(as maintainer of several commercial games in portage).

-- 
Chris Gianelloni
Developer, Gentoo Linux
Games Team

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

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

[Jeremy Maitin-Shepard]

Paul de Vrieze <pauldv@gentoo.org> writes:

> [snip]

>> Like I said, it would only have to ask for information that wasn't
>> available from the cache of answers.  Provided there was a tool to pre-edit
>> the cache - something I suggested earlier - then your scenarios would work.

> I agree with such a setup. Have a way in which - optionally - the ebuild can 
> be preconfigured. This configuration would need to be selfcontained in such a 
> way that the configuration files can be copied and created at any
> time. 

I much prefer requiring pre-configuration.  I don't like the idea of
emerge being interactive under any circumstance.

> ps. Besides this I feel the need to allow per-ebuild descriptions on useflags. 
> Those descriptions would describe what the consequences of the useflags are. 
> Like for subversion the berkdb useflag signifies whether the server part gets 
> build (because berkdb is needed for that), it would be very usefull to have 
> some easilly accessible description for it.

In this case, a "server" use flag would be more appropriate.  It is the
same reason that the X use flag should control whether x-chat builds
with X support or text support, rather than the gtk use flag.

-- 
Jeremy Maitin-Shepard

--
gentoo-dev@gentoo.org mailing list

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

[Marius Mauch]

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

On 05/01/04  Jeremy Maitin-Shepard wrote:

> Paul de Vrieze <pauldv@gentoo.org> writes:
> 
> > ps. Besides this I feel the need to allow per-ebuild descriptions on
> > useflags. Those descriptions would describe what the consequences of
> > the useflags are. Like for subversion the berkdb useflag signifies
> > whether the server part gets build (because berkdb is needed for
> > that), it would be very usefull to have some easilly accessible
> > description for it.
> 
> In this case, a "server" use flag would be more appropriate.  It is
> the same reason that the X use flag should control whether x-chat
> builds with X support or text support, rather than the gtk use flag.

I agree on the "server" USE flag, too bad my last attempt at it got a
lot of oppositions. Maybe it's different now (as we have package.use), I
don't know.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

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

[Paul de Vrieze]

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

On Saturday 01 May 2004 21:52, Jeremy Maitin-Shepard wrote:
> Paul de Vrieze <pauldv@gentoo.org> writes:
> > [snip]
> >
> >> Like I said, it would only have to ask for information that wasn't
> >> available from the cache of answers.  Provided there was a tool to
> >> pre-edit the cache - something I suggested earlier - then your scenarios
> >> would work.
> >
> > I agree with such a setup. Have a way in which - optionally - the ebuild
> > can be preconfigured. This configuration would need to be selfcontained
> > in such a way that the configuration files can be copied and created at
> > any time.
>
> I much prefer requiring pre-configuration.  I don't like the idea of
> emerge being interactive under any circumstance.

The optional (for the user, not the ebuild developer) configuration would 
happen before anything is downloaded, unpacked or compiled. Alternatively it 
should be possible to do this for a lot of hosts at the same time and just 
copy the configuration file(s) like what is possible with package.use

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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