Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
On Tuesday 23 August 2005 17:12, Jason Stubbs wrote: > > > > Wouldn't it better suit our needs to write a configuration program > > that packages can feed some custom configuration questions, and that > > then spits out something that can be used by the ebuilds. This would > > allow offline configuration of ebuilds etc. And something that was > > saved. > > This limits the possibilities of what can be done, no? For example, > answers determining the following questions or the selection of > questions based on how the package was installed. Indeed there could be > different questions based on whether it appears to be an upgrade or > fresh install. > > If the only benefits are being able to provide a consistent interface > and "offline" configuration, I don't really see the effort being worth > it. A usable interface abstraction can't really be created until the > requirements are known (which they're not due to pkg_config being > severely underused) and batched configuration can be done by creating a > text file with answers and piping. You're right. Such a program could anyway be used for most packages. That might currently be a better solution (and would limit the complexity of the program). Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpl4V2fH3yMF.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
On Tuesday 23 August 2005 22:41, Paul de Vrieze wrote: > On Thursday 14 July 2005 14:37, Jason Stubbs wrote: > > On Thursday 14 July 2005 20:58, Ned Ludd wrote: > > > echo "being that no portage dev in his/her right mind would > > > ever" echo "allow interactive code in an ebuild we use bashrc tricks" > > > > Actually, I promote interactive code in pkg_config(). There's no > > standard as to what it will do, so there's no real solution other than > > telling the user and then waiting for confirmation. > > > > As for the other phases, they should of course be 100% non-interactive. > > However, a pkg_presetup() or some such couldn't go astray - as long as > > it was purely optional. It would be much better to wait until portage > > supports arbitrary per-package env for it to be of any real use though. > > Wouldn't it better suit our needs to write a configuration program that > packages can feed some custom configuration questions, and that then > spits out something that can be used by the ebuilds. This would allow > offline configuration of ebuilds etc. And something that was saved. This limits the possibilities of what can be done, no? For example, answers determining the following questions or the selection of questions based on how the package was installed. Indeed there could be different questions based on whether it appears to be an upgrade or fresh install. If the only benefits are being able to provide a consistent interface and "offline" configuration, I don't really see the effort being worth it. A usable interface abstraction can't really be created until the requirements are known (which they're not due to pkg_config being severely underused) and batched configuration can be done by creating a text file with answers and piping. -- Jason Stubbs pgp6pSDTt1d8Q.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
On Thursday 14 July 2005 14:37, Jason Stubbs wrote: > On Thursday 14 July 2005 20:58, Ned Ludd wrote: > > echo "being that no portage dev in his/her right mind would > > ever" echo "allow interactive code in an ebuild we use bashrc tricks" > > Actually, I promote interactive code in pkg_config(). There's no > standard as to what it will do, so there's no real solution other than > telling the user and then waiting for confirmation. > > As for the other phases, they should of course be 100% non-interactive. > However, a pkg_presetup() or some such couldn't go astray - as long as > it was purely optional. It would be much better to wait until portage > supports arbitrary per-package env for it to be of any real use though. Wouldn't it better suit our needs to write a configuration program that packages can feed some custom configuration questions, and that then spits out something that can be used by the ebuilds. This would allow offline configuration of ebuilds etc. And something that was saved. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgph0MW7FFPPe.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
Kristian Benoit <[EMAIL PROTECTED]> wrote: > I just checked and pkg_config does not handle make menuconfig correctly > either :( Probably a bug. Sorry I didn't tune into this thread earlier... Most ncurses-based tools, including most menuconfig scripts, need to be attached to an interactive terminal in order to function properly. Some, and you mentioned vim as an example, include code to find a terminal. Some don't. Since emerge wraps everything for logging purposes, when you run menuconfig, it's attached to a pipe. What you'll probably need to do is something like make menuconfig 0/dev/tty || die "wombats!" which should attach dialog to your controlling terminal. -- Batou: Hey, Major... You ever hear of "human rights"? Kusanagi: I understand the concept, but I've never seen it in action. -- "Ghost in the Shell", Shirow Masamune pgpyiHUBK0ro4.pgp Description: PGP signature
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
On Thu, 2005-07-14 at 12:01 -0400, Michael Cummings wrote: > Not sure of the mechanics on how > this is done for the portage emerge process, but even stopping the > emerge process for those packages that *must* have a preconfig done > would help (are there any though? I can think of one maybe, but not > really anything to demand new functionality in portage yet). This problem is mostly present in the embedded world. As the packages have to be fine tuned (as a kernel is) at compiled time for the system on which it is beiing build. For example, uClibc and busybox uses a kernel like config. As described on busybox's home page: "BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system." With so many applications/options provided by a single package, that aim to go in small memory/storage system, one must understand that users must fine tune it. Kristian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Kristian Benoit wrote: > # ebuild path/to/ebuild config" > > I'm trying to do the same as config does, but in as a preconfig that > would only be also called on user request. > I'm just idly thinking here, and I'm sorry if this has already been said better - but I could see some value in an *optional* src_preconfig() function that allows you to run a manual config such as in the make menuconfig case - not required, but if present the ebuild breaks out with the einfo message, then when you go to run emerge again detects the change and carries on. Course as soon as I type this I realize that would require even more finangling since you would want to avoid clobbering with features=clean flags. Not sure of the mechanics on how this is done for the portage emerge process, but even stopping the emerge process for those packages that *must* have a preconfig done would help (are there any though? I can think of one maybe, but not really anything to demand new functionality in portage yet). 2 probably pointless cents on the matter, - -mike -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC1oxbq1ztTp5/Ti4RAh8hAJ4lgOVUpY5KKgwi5kuNuFNRqvt5rgCePCg1 GwezKKJ5hEJ3HU2XqL5DB7w= =sCo+ -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
On Thu, 2005-07-14 at 21:37 +0900, Jason Stubbs wrote: > On Thursday 14 July 2005 20:58, Ned Ludd wrote: > > echo "being that no portage dev in his/her right mind would ever" > > echo "allow interactive code in an ebuild we use bashrc tricks" > > Actually, I promote interactive code in pkg_config(). There's no standard as > to what it will do, so there's no real solution other than telling the user > and then waiting for confirmation. > > As for the other phases, they should of course be 100% non-interactive. > However, a pkg_presetup() or some such couldn't go astray - as long as it was > purely optional. It would be much better to wait until portage supports > arbitrary per-package env for it to be of any real use though. I just checked and pkg_config does not handle make menuconfig correctly either :( Probably a bug. One of my option was to unpack, config, merge (it would do the same, but you would have to know you must config after unpack)... I'm goiing to check how to fix that. :) Kristian > Regards, > Jason Stubbs -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
On Thu, 2005-07-14 at 08:43 +0200, Patrick Lauer wrote: > On Thu, 2005-07-14 at 01:13 -0400, Kristian Benoit wrote: > > What I want is "emerge busybox uclibc vanilla-sources nano". Should > > unpack only the 3 first packages, show me busybox menuconfig, uclibc > > menuconfig and vanilla-sources menuconfig and only then perform the rest > > of the installation as usual (without re-unpacking the 3 packages). > I really really hope that you want this to be a totally optional feature > that is never ever enabled by default. Of course it has to be totally optional and preconfig should be called before any packages compilation. So that you get every preconfig interactive prompt before everything else is done. > When I run emerge -uD world on a server I don't accept any ebuild > waiting for interactive input. For stagebuilding and other activities > this behaviour is also unacceptable. I wont accept that either :). > > And > > save the configs for futur use. So if my configs does not fit my need, > > re-emerging busybox with USE=savedconfig should get me the busybox > > menuconfig back using the previously configured ".config". > Patch the ebuilds with your .config Nope, it would just use the actual solution, use the one in /etc/busybox/busybox.config > > But anyway, the question is not whether the idea is good or not, but how > > to get a menuconfig that works within ebuild.sh (called from spawn in > > portage_exec ... called from the user with ebuild or emerge)? > *shudder* I hope this stays limited to your overlay. > > wkr, > Patrick -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
On Thu, 2005-07-14 at 07:58 -0400, Ned Ludd wrote: > On Thu, 2005-07-14 at 01:13 -0400, Kristian Benoit wrote: > > On Wed, 2005-07-13 at 20:02 -0400, Ned Ludd wrote: > > > On Wed, 2005-07-13 at 18:44 -0400, Kristian Benoit wrote: > > > > I'm trying to add a new command to ebuild (preconfig) for packages like > > > > But anyway, the question is not whether the idea is good or not, but how > > to get a menuconfig that works within ebuild.sh (called from spawn in > > portage_exec ... called from the user with ebuild or emerge)? > > Well portage is a non-interactive tool and it's staying that way. > For what you want you will need to edit the busybox/-sources/uClibc > ebuild and manually add in a call to make menuconfig. > Or add something like this untested example to your > local /etc/portage/bashrc I'm not trying to make it more interactive than it actually is. stated from: http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=3&chap=6#doc_chap3 "Performing Configuration Actions Some applications include instructions that configure the package further on your system. These instructions can be interactive and are therefore not automatically executed. To run these configuration steps, which are enlisted in the ebuild's (optional) config() function, use ebuild's config functionality: Code Listing 11: Configuring a package # ebuild path/to/ebuild config" I'm trying to do the same as config does, but in as a preconfig that would only be also called on user request. My goal is actually mostly learning portage internal so it might never do it's way into production and it might be fine like that. Thanks for the bashrc tip, I did'nt know that. Kristian -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
On Thursday 14 July 2005 20:58, Ned Ludd wrote: > echo "being that no portage dev in his/her right mind would ever" > echo "allow interactive code in an ebuild we use bashrc tricks" Actually, I promote interactive code in pkg_config(). There's no standard as to what it will do, so there's no real solution other than telling the user and then waiting for confirmation. As for the other phases, they should of course be 100% non-interactive. However, a pkg_presetup() or some such couldn't go astray - as long as it was purely optional. It would be much better to wait until portage supports arbitrary per-package env for it to be of any real use though. Regards, Jason Stubbs pgpyvIMopU91X.pgp Description: PGP signature
[gentoo-dev] Re: [gentoo-embedded] Interactive command
On Thu, 2005-07-14 at 01:13 -0400, Kristian Benoit wrote: > On Wed, 2005-07-13 at 20:02 -0400, Ned Ludd wrote: > > On Wed, 2005-07-13 at 18:44 -0400, Kristian Benoit wrote: > > > I'm trying to add a new command to ebuild (preconfig) for packages like > But anyway, the question is not whether the idea is good or not, but how > to get a menuconfig that works within ebuild.sh (called from spawn in > portage_exec ... called from the user with ebuild or emerge)? Well portage is a non-interactive tool and it's staying that way. For what you want you will need to edit the busybox/-sources/uClibc ebuild and manually add in a call to make menuconfig. Or add something like this untested example to your local /etc/portage/bashrc if [[ $EBUILD_PHASE == compile ]]; then case "$PN" in busybox) uclibc) *-sources) echo "we are at the stage where portage has unpacked the " echo "ebuild and is getting ready to compile." echo "being that no portage dev in his/her right mind would ever" echo "allow interactive code in an ebuild we use bashrc tricks" echo "here to get what Kristian is after" /usr/bin/make menuconfig || exit 1 ;; esac fi -- Ned Ludd <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-embedded] Interactive command
On Thu, 2005-07-14 at 01:13 -0400, Kristian Benoit wrote: > What I want is "emerge busybox uclibc vanilla-sources nano". Should > unpack only the 3 first packages, show me busybox menuconfig, uclibc > menuconfig and vanilla-sources menuconfig and only then perform the rest > of the installation as usual (without re-unpacking the 3 packages). I really really hope that you want this to be a totally optional feature that is never ever enabled by default. When I run emerge -uD world on a server I don't accept any ebuild waiting for interactive input. For stagebuilding and other activities this behaviour is also unacceptable. > And > save the configs for futur use. So if my configs does not fit my need, > re-emerging busybox with USE=savedconfig should get me the busybox > menuconfig back using the previously configured ".config". Patch the ebuilds with your .config > But anyway, the question is not whether the idea is good or not, but how > to get a menuconfig that works within ebuild.sh (called from spawn in > portage_exec ... called from the user with ebuild or emerge)? *shudder* I hope this stays limited to your overlay. wkr, Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
[gentoo-dev] Re: [gentoo-embedded] Interactive command
On Wed, 2005-07-13 at 20:02 -0400, Ned Ludd wrote: > On Wed, 2005-07-13 at 18:44 -0400, Kristian Benoit wrote: > > I'm trying to add a new command to ebuild (preconfig) for packages like > > busybox that has to be configured prior to compile and that would be a > > cannot really use USE as it probably have undreads of USE that does not > > yet exist. > > > > That new command would be called between src_unpack and src_compile and > > only if FEATURES contain preconfig. > > What you want already exists. Enable USE=savedconfig > Then add an /etc/busybox/busybox.config > Then merge busybox. I know that this option exist, but I must either download busybox by myself, make menuconfig by myself and copy it to the right location by myself or ebuild unpack and do the rest by myself. It look pretty much as a patch to me, cause portage cant handle packages that has to be user configured before compile time. What I want is "emerge busybox uclibc vanilla-sources nano". Should unpack only the 3 first packages, show me busybox menuconfig, uclibc menuconfig and vanilla-sources menuconfig and only then perform the rest of the installation as usual (without re-unpacking the 3 packages). And save the configs for futur use. So if my configs does not fit my need, re-emerging busybox with USE=savedconfig should get me the busybox menuconfig back using the previously configured ".config". But anyway, the question is not whether the idea is good or not, but how to get a menuconfig that works within ebuild.sh (called from spawn in portage_exec ... called from the user with ebuild or emerge)? Kristian > Have fun. > > > -- > Ned Ludd <[EMAIL PROTECTED]> > -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [gentoo-embedded] Interactive command
On Wed, 2005-07-13 at 18:44 -0400, Kristian Benoit wrote: > I'm trying to add a new command to ebuild (preconfig) for packages like > busybox that has to be configured prior to compile and that would be a > cannot really use USE as it probably have undreads of USE that does not > yet exist. > > That new command would be called between src_unpack and src_compile and > only if FEATURES contain preconfig. What you want already exists. Enable USE=savedconfig Then add an /etc/busybox/busybox.config Then merge busybox. Have fun. -- Ned Ludd <[EMAIL PROTECTED]> -- gentoo-dev@gentoo.org mailing list
