Michał Górny posted on Wed, 04 Jul 2012 22:38:50 +0200 as excerpted: > On Wed, 4 Jul 2012 20:06:58 +0200 Tobias Klausmann <klaus...@gentoo.org> > wrote: > >> On Wed, 04 Jul 2012, Michał Górny wrote: >> > There's a very simple yet custom solution I'm using. Shortly saying: >> > checkout the kernel git to /usr/src/linux and chown to your user. As >> > far as it goes, it's superior to having kernel sources installed by >> > ebuilds. >> > >> > I just have to remember to do 'git fetch' from time to time and 'git >> > merge' whenever a new version is tagged. >> >> It is also beyond the package manager's control. That means users who >> want to just configure their kernel (and run point releases otherwise) >> have to actively check for new tags/versions. > > True. I think that's the direction I should look into improving. > >> Aside from that the git tree is not exactly lightweight: my current 2.6 >> checkout weighs in at 1.4G whereas the unpacked tar is 512M. > > Well, that's the other problem. On the other hand, you usually have to > have that 1G free anyway unless you intend to manually unmerge the > previous *-sources before installing the new one. And the time needed to > do that... git is so much faster.
I'll second the git being faster bit. What's especially nice about it is that checking out and building any arbitrary tag (release or rc), or for that matter, doing a bisect down to an individual commit, if you're trying to track down some issue or other, is really easy. [1] But the main reason for this reply is to add this idea: Here, I have my regular user, and I have my admin-hat user. My regular user has sudo locked down quite strictly, with a password required for anything not specific parameter locked, etc. But, the one thing the regular usr CAN do, is sudo (with password) to the admin user. Additionally, my regular user isn't in the portage, wheel, etc, groups either (and polkit is generally locked down for it as well), so it really is quite privilege-locked, EXCEPT that it can sudo to admin. The admin user then has unrestricted passwordless sudo access. Basically root, except that I can type the command unprivileged first, then when for instance the rm gives me the expected permissions error, I can see that it's what I did indeed intend to rm, and arrow-up, home, sudo in front, to actually do it. The admin user is then what I use to git pull and build the kernel, so that's the only user (other than root) with write access to the kernel sources. My normal user doesn't have that access, thus avoiding the normal-user-writable security issue mentioned in your (klausman's) blog. Since that admin user then has unrestricted passwordless sudo, sudoing (from that admin user) to root for the actual install is trivial. Meanwhile, I actually have a set of kernel maintenance helper scripts that I use to update, configure (either oldconfig for the update or just to change something...), build and install the kernel. They're not ready for use by the general public yet, but they're a reasonable start, including a configuration file for most stuff one might want to change (where the kernel dir is located, where the output dir is located so as to keep the sources dir itself clean if so desired, whether to auto- mount /boot for installation, etc). There's even provision for automatically applying patches from a user patches dir! =:^) Since I've been running a git kernel for several years now, the git- kernel scripts are current, but I did start on the scripts back when I was still using tarballs, so there's scripts that automate most of that, as well, tho they're a bit stale now as I've not actually run/tested them in a couple years (but I did try to update them for the 3.0 kernel, etc). If you'd like, I can email them. As I said, they're not really fit for public consumption yet, but it's a reasonable start including a config file, and I use it for maintaining my systems (both x86 and amd64, separate output dirs based on the bash ARCH variable) here, with a maturity and development over several years, so if you're interested in /making/ them fit for public consumption, it'd certainly save quite some days work over starting from scratch. Obviously I'm running/testing the scripts as a gentoo user, but other than perhaps some of the config file comments, there's not a whole lot specific to gentoo about 'em. --- [1] I routinely run live-git kernels, but don't like to run anything before rc1 until some days later, just in case. So when a release comes out, I'll often update a couple days into the new cycle, and then simply checkout and build the release tag. Then sometime after rc1 or rc2, I update again, and test from there. I figure if I need to bisect anything, news of any too drastic data-eating bugs pre-rc1 should be available, and I can then bisect back into the previously blackout period with a bit more confidence. -- 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
