On Fri, Nov 11, 2011 at 10:48:15AM +0100, Tom???? Chv??tal wrote: > 2011/11/11 Brian Harring <ferri...@gmail.com>: > The build issue was with -cups so useflag was removed and hard > dependency enabled, fine with me. > But why the fuck the bump was issued next day still hard-depending on > it and in day after that this commit arrived in: > > http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-16.0.912.32.ebuild?r1=1.1&r2=1.2 > > You are telling me this is build time failure fix, you are telling me > that people that already had pulled in that cups could not sleep > thanks to it and survive for another week to get the flag back with > bump?
I'm telling you to stop fucking bitching about running unstable software that probably is the fastest moving upstream in the tree in terms of versions, nor the simplest fucking thing to maintain, let alone keep everyone happy. Libreoffice I have no doubt is a pain in the ass to maintain, but I'd take it over chromium any day of the week. Realize you're ranting on the ML because /you choose to run unstable/ and don't like that it's changing to deal w/ bugs (let alone the fast release cycle of dev channel which you're on). Specifically, you're ranting, and I strongly suspect you didn't bother talking to the people directly beyond firing off bitching to the ML. Nice and friendly, that. As I said, looking through the logs it looks like this isn't arbitrary random fucking around w/ ebuilds as you're implying above. Is the cups situation a fuckup? Perhaps, but in digging through the logs it ain't seeming like it's the norm. It's more seeming like you're just venting about changes that went out fixing chromium building for others, and you had to rebuild. Productive courses of action, enumerated: 1) change your user configuration. You chose to run unstable after all. 2) talk w/ the devs directly w/ suggestions of how to slow the releases (doesn't frankly seem all that viable, but hey, it's your time to burn). Keep in mind your original suggestion was to leave shit broke in unstable (but hey, at least you don't have to recompile). 3) add an optional feature to portage enabling you to control the frequency of rebuilds for an unstable pkg. This way you get your bleeding edge, just control the level of pain. Non-produtive courses of action, enumerated: 1) bitching on an ML cc'ing the maintainers rather than going to the maintainers directly. 2) continuing to argue with me. ~brian
