Gather round the fire kids, while I remind you all why we don’t blindly accept user submitted ebuilds without consequence. I will refrain from naming packages or bug numbers, but our newer devs might garner a lesson in all of this. (yes, I’m tired enough to rant profusely today)(and further yes, adding a web interface to nanoblogger makes for a louder mcummings).
You haven’t been around long if you haven’t seen at least one user submitted ebuild. I see them all the time, and usually decide based on general interest and supportability whether it is feasible to add to the tree, accepting that once I do so the bugs will come knocking to me. But sometimes we make mistakes.
I accepted into the tree an ebuild to help users access an online service. It’s one that people I know use, that I could test with my wife’s account (so it isn’t that kind of package), and all in all it seemed ok. The author used some questionable (to me) techniques in the ebuild, but nothing that would bring Mr.Bones knocking on my door with his scythe in hand.
Then the bug came. It turns out I was completely incompetent in adding the ebuild; it was missing DEP’s, its used a mile long sed statement that was better served with a quick patch, and although serviceble, it was shameful to have my name in the ChangeLog as the initiator. To make the author of the ebuild aware that A) a bug existed and B) I was making changes, I went through my backlog and added his account to the bug.
Except now he’s not “happy” with the changes I’ve made to the ebuild, arguing that a sed that stretches 6+ lines is better than just using a simple patch, and to boot thinks the sed should be expanded. Now I find myself in a tough spot, because although I added it to the tree, and there are at least a few users that use it or there wouldn’t be bugs from people discovering flaws, I would love nothing more than to drop it from the tree all together and wash the history banks of any memory of it. The app is functional and does what it claims, there isn’t anything in the tree that does the same thing, but it’s *ugly* in implementation, and I suspect it was originally intended for the author and a few of their friends to pass around, and not for a mainstream distribution* (as evidenced by some of the hacks we have to use to make it usable from /usr/bin/). [*I mean distribution in terms of dissemination, not trying to claim Gentoo is a mainline distro – that’s for you to decide]
GAH – the moral of this tale friends is if you’re going to be nice, make sure you’re willing to accept the consequences. Now I’m going to have to go back to this bug, and maybe this blog entry will find its way into the DO’s and DON’Ts of a future “welcome to gentoo dev manual.” But no good deed goes unpunished. Ever.