On 11/04/2013 03:46 PM, Duncan wrote: > 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! =:^) >
I'd be very interested in this kernel config script you have! I want to set up a mini ITX system as a NAS some day, and since it runs an Intel Atom, I'm likely going to be building the packages on my desktop.
