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 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 1/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 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
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
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=3chap=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 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 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
-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 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
