Martin Vaeth posted on Mon, 04 Nov 2013 11:17:49 +0000 as excerpted: > Duncan <1i5t5.dun...@cox.net> wrote: >> >> and the default is oneshot > > I would always recommend to put -1 into EMERGE_DEFAULT_OPTS; > you can still use --select if you really want a new package in a word > file: after the first installation this should happen rather rarely (and > you can still use -n --select later on if you forgot it and realize that > depclean wants to remove it).
I imagine were emerge being written today, -1 /would/ be the default, and there'd be an option like --select to add to the @world file if necessary. That's actually the way I setup my scripts, with -1 the default, and an extra "2" suffix script variant that did add to the world file. But backward compatibility being what it is, I guess by the time portage authors realized they had a backward default, they couldn't really fix it, except by something like EMERGE_DEFAULT_OPTS. >> Then there's esyn, which syncs both the gentoo tree and layman, as well >> as automatically handling ebuild patching and redigesting > > You can use eix-sync for that [...] > > The advantage is that you will probably have a better behaviour in case > some of the tasks fail... Again, if it were available (and something I knew about) back in the day... I might have ended up with that. However, I've come to appreciate an advantage to writing one's own scripts -- bug fixing or adding new functionality is a *LOT* easier since you're already familiar with the code. In fact, speaking from experience, adding support for a new feature to a script you've created yourself is often easier than figuring out the new config options for the same feature for an upstream script, when they add support for it! Plus, you don't have to worry about learning new config options for new features you'll never use, since you simply don't code them in the first place. =:^) The ebuild-patching tree and auto-redigest features were in fact recent adds, when I needed something that scaled better than one-off ebuild editing during the time gentoo/kde dropped support for USE=semantic- desktop and I had to carry my own patches to kill it. (FWIW, they've since reverted and offer USE=semantic-desktop again now, THANKS gentoo/kde! =:^) Similarly, adding git functionality to my existing kernel scripts wasn't difficult, and arguably easier to do since I knew the code, than trying to reverse engineer the new config options and perhaps the supporting code behind it, were I using an upstream solution that added git kernel support to existing helper scripts. >> I have a similar set, but starting with k* instead of e*, for automatic >> mainline kernel fetching, building, etc. > > This is rather cumbersome, since you should have different permissions > for building and installing (if you use the recommended way to build > into a separate KBUILD_OUTPUT with e.g. portage permissions). > Except for fetching, you might want to use the kernel script from the mv > overlay. Actually, both different building/installing permissions (via config file sudo option, tho I'll admit since I set that the option, running with that option turned off isn't tested, but the basic script infrastructure for it is there), and KBUILD_OUTPUT (setting in the config file) are already supported. =:^) And talk about ease of adding functionality, when I setup my 32-bit netbook build chroot, it was just a few lines changed in the kernel scripts themselves, and a "dynamic config" line added to the config file (which is sourced, so accepts both var=val style and dynamic config script snippets) to auto-detect which system I was building for and set KBUILD_OUTPUT accordingly, thereby keeping the work dirs and config entirely separate, automatically, via "dynamic config". Trivial feature-add, and now that it's there, if I suddenly needed to scale to 100 or 1000 different kernel configs, that'd be even more trivial (even just a config file change), if necessary by having the config file source yet another "separate-builds.conf" file with its own dynamic-config logic to choose between the different configs. This sort of solidly sysadmin level helper/glue script is something Unix/ Linux/Gentoo is well optimized to make not only possible, but trivial, to implement, and I definitely put that feature to use! =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
