Since I use Gentoo a lot for developing non-Gentoo open source software, I've been giving some thought as to how I can streamline my working environment.
I think that we already have an upper hand over other distro's - Gentoo's natural environment includes a fully functional build environment, whereas I think you really need to set up a separate environment or install many packages marked as "-devel" on other distro's (I might be talking rubbish here, I haven't played much with other distro's for a while).
So, we're already well geared for this sort of thing, but I can think of numerous ways that things can or should be improved. Most of the things I'm thinking of are just small, but would certainly help streamline my style of working.
I recently started a quick discussion on this on the gentoo-dev mailing list, quoting one example of something I'd like to address. Many of the responses were along the lines of "you can do this already - just write an ebuild". To give some perspective, I regard writing an ebuild for a relatively simple development task as too much slowdown. Especially when an equivalent ebuild has already been written.
Updates about this venture can be found on my weblog.
Since the release of Portage 2.0.51, the portage developers have been doing some pretty rapid development, which appears to be mainly focused on new features, rewriting bottleneck code, and improving general performance. There's some other good news in here: there's a few features which really help make progress to improving gentoo as a development platform.
Portage-CVS (aka HEAD) is progressing quickly but has no guarantees for stability. If this software burns your house down, you are to blame for installing it in the first place. Don't expect it to be flawless at this point in time.
That aside, here's how to install it on your running system:
cvs -d YOURUSERNAME@cvs.gentoo.org:/var/cvsroot co gentoo-src/portage cd portage
# So that non-root users can use ebuild wget http://dev.gentoo.org/~dsd/development-platform/portage-configurable-uid-gid.patch -O- -q | patch -p1
./autogen.sh ./configure make dist cp portage-cvs.tar.bz2 /usr/portage/distfiles
emerge -av sandbox
emerge -av --digest portage
If you applied the configurable-uid-gid patch earlier, you can now use ebuild as a regular user, if you set up the environment properly.
To do this, I've created a wrapper which I've named dpbuild. For now, it just sets some environment variables, but will probably be extended in the future to achieve some of the more intrustive hacks I'm considering.
dpbuild can be found here. I suggest that you put it in /usr/local/bin and make it executable.
So, one of the first scenario's I attempted to "optimize" was the patching of an existing package. More specifically, I wanted to fix bug 74285, by adding another patch to sys-apps/gamin.
The patch I was trying to add (from the GNOME bugzilla) applies against gamin-cvs but not the latest gamin-release. I was hoping to use portage to make the sources available, and then to produce a rediff of the patch.
Unfortunately, too much has changed in gamin-cvs for the patch to work with the latest release. So while this was somewhat a failure, two things were gained out of it.
The first, was that I added dev-util/rej to the tree. rej is a utility which attempts to automatically solve diff/patch rejects. I attempted to apply the patch to gamin, and many hunks failed. rej was able to automatically correct a fair proportion of these - this would have been very useful, should the whole operation have not been a total waste of time! Also, wiggle has been mentioned recently, which may also be worth looking into.
The other useful thing, was the birth of dpbuild (see above). This allowed me to, as a normal user, do the following:
ecd gamin # ecd is from ciaranm's bashrc collection dpbuild gamin-0.0.26-r6.ebuild unpack cd /home/dsd/builddir/portage/gamin-0.0.26-r6/work
At this point, I have the portage-processed gamin source at my fingertips, without having to be root or mess with permissions. Of course, there is room for further improvements there, I'm willing to argue that the above 3 commands should be merged into one. I'll leave that for another day.
Todo: Write about this.
Here's a few idea's I'll be working on:
- Daniel Drake (dsd@gentoo.org)
Much of this is discussed on my weblog.