Unifying PostgreSQL Ebuilds
After an excruciating wait and years of learning PostgreSQL, it’s time to unify the PostgreSQL ebuilds. I’m not sure what the original motivation was to split the ebuilds, but, from the history I’ve seen on Gentoo, it has always been that way. That’s a piss-poor reason for continuing to do things a certain way. Especially when that way is wrong and makes things more tedious and difficult than they ought to be.
I’m to blame for pressing forward with the splitting the ebuilds to
-server when I first got started in Gentoo. I knew from the outset
that having them split was not a good idea. I just didn’t know as much as I do
now to defend one way or the other. To be fair, Patrick (bonsaikitten) would
have gone with whatever I decided to do, but I thought I understood the
advantages. Now I look at it and just see disadvantages.
Let’s first look at the build times for building the split ebuilds:
1961.35user 319.42system 33:59.44elapsed 111%CPU (0avgtext+0avgdata 682896maxresident)k 46696inputs+2000640outputs (34major+34350937minor)pagefaults 0swaps 1955.12user 325.01system 33:39.86elapsed 112%CPU (0avgtext+0avgdata 682896maxresident)k 7176inputs+1984960outputs (33major+34349678minor)pagefaults 0swaps 1942.90user 318.89system 33:53.70elapsed 111%CPU (0avgtext+0avgdata 682928maxresident)k 28496inputs+1999688outputs (124major+34343901minor)pagefaults 0swaps
And now the unified ebuild:
1823.57user 278.96system 30:29.20elapsed 114%CPU (0avgtext+0avgdata 683024maxresident)k 32520inputs+1455688outputs (100major+30199771minor)pagefaults 0swaps 1795.63user 282.55system 30:35.92elapsed 113%CPU (0avgtext+0avgdata 683024maxresident)k 9848inputs+1456056outputs (30major+30225195minor)pagefaults 0swaps 1802.47user 275.66system 30:08.30elapsed 114%CPU (0avgtext+0avgdata 683056maxresident)k 13800inputs+1454880outputs (49major+30193986minor)pagefaults 0swaps
So, the unified ebuild is about 10% faster than the split ebuilds.
There are also a few bugs open that will be resolved by moving to a unified
ebuild. Whenever someone changes anything in their flags, Portage tends to only
dev-db/postgresql-server as needing to be recompiled rather than the
dev-db/postgresql-base, which results in broken setups and failures
to even build. I’ve even been accused of pulling the rug out from under people.
I swear, it’s not me…it’s Portage…who I lied to. Kind of.
There should be little interruption, though, to the end user. I’ll be keeping
all the features that splitting brought us. Okay, feature. There’s really just
one feature: Proper slotting. Portage will be informed of the package moves, and
everything should be hunky-dory with one caveat: A new
server USE flag is being
introduced to control whether to build everything or just the clients and
No, I don’t want to do a lib-only flag. I don’t want to work on another hack.
You can check out the progress on my overlay. I’ll be working on the updating the dependent packages as well so they’re all ready to go in one shot.