[gentoo-dev] FEATURES to cut the excess in portage
Two patches which allow a user to bypass files created with doman and dodoc in FEATURES: FEATURES=noman nodoc emerge -av foo http://jawed.name/dev/gentoo/nodoc.patch http://jawed.name/dev/gentoo/noman.patch Quick background/inspiration: I found myself having to make an initrd suitable to do PXE boots for our business and educational clusters. I was exploiting the ever so useful ROOT option for portage to emerge packages into the initrd build directory. However, because this was an initrd being sent over the network, total size was important. At larger sizes the loading the initrd would actually cause a kernel panic on pivoting root...whether this was a result of a kernel config, a set maximum size limit, or something else I'm not exactly sure of. Looking at the output of du, I started first by removing the man and documentation files. This brought the size of my final initrd down significantly (~287MiB to ~242MiB). Possible issues/bigger picture: While I was making the changes to doman and prepman, I kept thinking of how this really is part of a bigger picture, [I think] maybe the whole minimal concept should be abstracted out of USE (for packages that have it) and be part of FEATURES (for all packages). In my case because I was using ROOT in portage to build out an initrd, I didn't really need or want man or documentation for the packages I was putting in. At the end of the day, maybe there should be a specific mix of FEATURES such as nodoc noman and/or a granular mix of minimal which encompasses the previous+more. Obviously it's open for a lot of discussion and the patches attached should/would probably not be a final solution...the goal was that this would be a start. We've been using this patch and it's worked out for us well. Your mileage may vary, if it does, please say something! :-) Thanks, John PS Sorry to the devs I was working with (you know who you are :-) for my inactivity lately...moving my life 1600 miles on a weeks' notice hasn't exactly been the easiest thing, definitely hasn't helped for the free time column. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] FEATURES to cut the excess in portage
Ah yep, missed it. Nevermind my chatter :-) On 11/5/06, Tobias Scherbaum [EMAIL PROTECTED] wrote: Am Sonntag, den 05.11.2006, 20:08 +0100 schrieb Christian Heim: On Sunday, 05. November. 2006 19:02, John Jawed wrote: Two patches which allow a user to bypass files created with doman and dodoc in FEATURES: FEATURES=noman nodoc emerge -av foo http://jawed.name/dev/gentoo/nodoc.patch http://jawed.name/dev/gentoo/noman.patch Err, isn't current portage already having FEATURES=noman and nodoc ? At least last time I used it, it was there ... Don't forget about noinfo ;) Tobias -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
Updated version is up at http://jawed.name/dev/gentoo/einput.eclass now. Regards, John Open source, you don't pay back, you pay forward. On 7/24/06, Alex Tarkovsky [EMAIL PROTECTED] wrote: To ensure the global vars play nicely in the Portage environment I've renamed a few, and moved a couple more to functions as locals and literal strings. Also improved on the inline documentation and renamed a couple of functions to something more intuitive. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
Alright, now it's the latest. Regards, John Open source, you don't pay back, you pay forward. On 7/24/06, Alex Tarkovsky [EMAIL PROTECTED] wrote: On 7/24/06, John Jawed [EMAIL PROTECTED] wrote: Updated version is up at http://jawed.name/dev/gentoo/einput.eclass now. The version you have up there isn't the latest actually, see the attachment in the post you just replied to. :) -- gentoo-dev@gentoo.org mailing list -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
Alex, Nice work on this, it's looking good now. Is there a reason the leading asterisk was dropped? Having it there might be good for readability as well as keeping in line with the look here (einfo, eerror, ewarn, etc) motif in portage. I will be testing and reporting back my results, encourage others to do the same for their terminals as well. Thanks, John Open source, you don't pay back, you pay forward. On 7/23/06, Alex Tarkovsky [EMAIL PROTECTED] wrote: Attached is an overhaul of John's code. Aside from some bugfixes and readability improvements, the most significant changes are: - Renamed functions to follow de facto and emerging Portage API naming conventions. - Validation of input for the list prompt and confirmation prompt functions. - Added more terminal color codes, based on the codes from Portage's output.py module. - Improved handling when Portage's NOCOLOR environment var is set. I've left some test code at the end to make it easy for everyone (and I do mean everyone; this sucker needs a lot of testing) to try out the various interactive prompts this eclass provides -- just run the eclass directly and have fun. You can also run it in no color mode thusly: # NOCOLOR=true ./einput.eclass If your system is already set to no color by default, you should be able to turn on color like so: # NOCOLOR= ./einput.eclass -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: Einput eclass
Updated version, revised to use Gentoo supplied color codes (thanks to shillelagh for pointing me to these). http://jawed.name/dev/gentoo/einput.eclass Also cleaned up logic in displayListPrompt. Regards, John Open source, you don't pay back, you pay forward. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
Brian, I was looking through /usr/bin/emerge and lines 3477-3481 seemed to best fit what displayConfirmPrompt is trying to supplement. The check on line 3477 is against a No returned from userPrompt(), and then a system exit code is issued by caller (line 3481). Was unable to find any other instance of the function being called issuing a system code in the emerge code, could you please point me in the direction you wanted me to go with this? On 7/20/06, Brian Harring [EMAIL PROTECTED] wrote: Examples of converted ebuilds would be wise prior to plopping it into the tree imo- fex, displayConfirmPrompt looks like it should be reliant on exit codes rather then mangling a global var to indicate the outcome; that would shift it more towards get confirmation rather then display. Thank you for the kudos Doug. On 7/20/06, Doug Goldstein [EMAIL PROTECTED] wrote: John, I think you've done a really great job with this. Very creative and good initiative. You're hired. Someone get him his developer badge.. Regards, John Open source, you don't pay back, you pay forward. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Einput eclass
There are two ebuilds which use this currently:
http://jawed.name/dev/gentoo/openfts-0.39.ebuild
http://jawed.name/dev/gentoo/dev-db/pgfouine/pgfouine-0.6.ebuild
The code used to generate the screenshot got lost in the initial
posting, here it is:
pkg_config() {
displayListPrompt 1 List Entry 2 List File Choose a listing
style
einfo
displayConfirmPrompt Are you sure you want to rm -rf /?
einfo
displayQuestionPrompt Is Gentoo a good Linux distro? Yes it is Jim
einfo
displaySQuestionPrompt Please enter your root password
}
On 7/20/06, Luca Longinotti [EMAIL PROTECTED] wrote:
I'm willing to put this eclass in the tree and maintain it myself for now, and
when John
become a full Gentoo dev (this is already scheduled, he'll help out on
PostgreSQL related stuff in the near future), he can take it over
directy... Any objections to this wandering into the tree?
Thanks Luca!
On 7/20/06, Brian Harring [EMAIL PROTECTED] wrote:
Examples of converted ebuilds would be wise prior to plopping it into
the tree imo- fex, displayConfirmPrompt looks like it should be
reliant on exit codes rather then mangling a global var to indicate
the outcome; that would shift it more towards get confirmation
rather then display.
Makes much more sense, I will get to work on converting those to exit codes.
Regards,
John
Open source, you don't pay back, you pay forward.
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] Einput eclass
Below is a link to an enhanced input eclass as well as a screenshot. This eclass was made to simplify interacting with the user at pkg_config(). http://jawed.name/dev/gentoo/einput.eclass http://jawed.name/dev/gentoo/einput.png (code used to create this output is below) This eclass started off as a small set of scripts used by academia at my current campus and eventually was built upon. I was the original author and modified it later to be ebuild friendly. It has support for serial consoles. The main purpose of this eclass is to make life simpler for developers that try to streamline --config interaction. For example, having --config with net-proxy/squid may ask for where to create the swap directories, sed the config and then issue a squid -z for the user. Taking it further, it may ask if the user wants the --config to add the runlevel init scripts. Upgrades to packages which require conversion of data catalogs (such as MySQL/PostgreSQL data directories) could also be streamlined with user interaction. In general, I think having more post install configurations to streamline the basics for core packages will be beneficial to both Gentoo newcomers and gurus. The einput.eclass should help Gentoo developers lives easier in achieving in that goal. I would like to continue to build upon this eclass. Regards, John -- gentoo-dev@gentoo.org mailing list
