I forked this package a few days ago and released 3.0 which makes a clean departure from the original shell script. BIG FAT NOTE: I may be the only person who cares about this script, so this bug can be totaly ignored in that case and resolved as fixed ASAP. However, an ebuild is in the offial tree. So, adding a new versioned ebuild makes sense. I cleaned up the mess of hprofile-2.0_beta2. The original author, Martin Aspeli, made several noticeable points to insist to not do *stupid things* with this script. Well, he--himself--made a few noticable one like writing a one hundred line script, hpdet to name one, to only execute a single command--namely: run $profile_dir/hpdet--using a shell and a sub-shell. This is done with single line (well, actually 4 because this script is now sourced in a function block: function hpdet { source "$profile_dir/hpdet" } hpdet ) in hprofile-3.0 to avoid firing up numerous unecessary sub-shells to just execute a single command or two at the least. hprofile-2.0_beta* is a disaster performance wise with numerous unecessary sub-shell and dsk seeks to run a single command. Hopefully, this script was/is used for very simple things. The ChangeLog says: --- 3.0: * cleaned the mess to have a KISS script: 1. no need to have multiple sub-shell to be able to move a few files and run a few commands; 2. speed/effiency wise, the previous version was a disaster, hopefully this script was used for simple things; 3. who need hundreds of lines to move a few files and exec a few cmds?! * changed *API*: 1. no +x executable bit needed anymore as everthing can be runned in a single shell, so source-ing is prefered for efficiency/speed; 2. as exececuted scripts are sourced, scripts have access to internal helpers to use; 3. <profile-dir>/{star,stop} are common scripts for profile scripts if present, so those can be used as a common start/stop script; 4. <profile-dir>/script_name.bash are recognized and script_name_bash hold the path of the script, so those script can be used/sourced in a nice and simple way (see disk profile); 5. user profile are now properly handled in the same maner as system profiles, there is a -u|--user=$USER to specify the specific user so runtime profile is set to $HOME/.hprofile. * numerous fixes/clean ups... --- Indeed, It tooks me to much time to clean the mess out of a simple script and get rid of the *novel* part of it. (Yes, the original script is novel in its own; the README is *realy* a *novel*, more than 400 lines! to state a single usefull statement. I do remeber being overwhelmed by it the first I tried write a *profile* although I did manage to write a few, notably those listed the hprofile wiki page.) You may say this bug report is a *novel* in its own. It is! I'm just trying to convice... Anyway, an ebuild is available here: https://github.com/tokiclover/bar-overlay/tree/master/sys-apps/hprofile with DEPEDN/RDEPEND fix because hprofile need diffutils, findutils, version 3.0 need sed to get the first line of a file (maybe an overkill but grep/cat+head... two commands for just that...)
HOMEPAGE: https://github.com/tokiclover/hprofile of the project.
And 3.0 fix bug #216716 because it has a Makefile with use of prefix variable, so `prefix=/' install to `/bin'. I don't like that, stuffing `/bin' with shell scripts, but it does fix that issue.
Maybe a USE flag can be added for comment #2... for installation.
This bug fix bug #445744 as the init script has a PROFILES variable where users can chose boot profiles, making that old patch unecessary. Somebody has to mark both cited bugs as fixed by this! Oh well, it seems bgo lacks manpower at the moment because of inactivity noticed in other bugs or this one while... Well, I can temporary proxy maintains this package as there is nothing to do in ebuild.
should be all set now in the tree; thanks for the report! Commit message: Version bump http://sources.gentoo.org/sys-apps/hprofile/hprofile-3.0.5.ebuild?rev=1.1
This time, it's me who is too slow! Well, should I open a new bug for this? Hear me first, or rather, read the following. I've just released 4.0.x the other day and that major update make a departure from bash to zsh. This departure just make it easy to have everthing--even the extra profile scripts (.zsh files in this case)--fixing the issue mentionned in comment #1: unability to define function with a variable (bash treat as literal what follow *function* keyword). What the hell is this feature? Well extra profile scripts can be used with simple call by file name (file name hold function name of the same file). So easy! No need to repeat function definition as the bash counter part (as can be seen in the bundled disk profile.) There is already a stable 4.0.1 release! Cheers.
