Apparently, though unproven, at 01:29 on Thursday 10 February 2011, Carsten Haitzler did opine thusly:
> On Thu, 10 Feb 2011 00:26:11 +0200 Alan McKinnon <alan.mckin...@gmail.com> said: > > Apparently, though unproven, at 14:28 on Wednesday 09 February 2011, P > > > > Purkayastha did opine thusly: > > > >> dont use ANY --enable/disable configure flags. defaults are what you > > > >> want. using any such flags you do at your own risk. > > > > > > > > That breaks Gentoo in all sorts of horrible ways. > > > > > > Strange. My broken e17 + gentoo is somehow chugging along for a good > > > 4th year now ;) > > > /me starts looking for the broken pieces ... > > > > I don't mean it breaks Gentoo such that bits of EFL lie all over the > > floor right away. > > > > Gentoo, by design, lets the user control what features are installed and > > what is not installed via USE flags. This sets up dependencies. > > > > When a build script on Gentoo relies on automagic enabling of features, > > only stuff that is already present is used. This is NOT up to some > > distro packager, it is up to the user. There is no method to set up > > optional dependencies so the usual route is to DEPEND on nothing and > > rely on magic (or user vigilance) or DEPEND on everything which makes > > the average Gentoo user freak out. > > > > emerge --depclean is then useless at helping remove unneeded deps later > > on. > > > > But you know all this already right? > > > > Developers can by all means use automagic deps; I'm opposed to the > > practice myself but I can't stop devs doing it. But also provide > > explicit --enable/-- disable options in ./configure for source based > > distros. > > gentoo allows users to configure the builds of their libs. this also allows > them to shoot themselves in their feet and screw it up. eg disable a > feature and then find that e17 needs it. and then the gentoo users come > running here to us e devs complaining e is broken and how they should fix > it. gentoo is broken already. it just foists work onto US developers as > users do things they have not the slightest clue about. those swizzle > knobs are for people who know what the hell they are enabling or disabling > and what the consequences will be. > > this problem has gotten so bad that i'm becoming of the opinion that we > should cease having any configuration you can change at compile time > because it was never intended to be exposed to "users". but it is and its > causing US trouble and US work because gentoo is going around doing just > that. the result will be that people who want to change things for > specific good reasons and know what they are doing now have to PATCH the > build rather than just provide some --enable/disable flags. > > so to gentoo... STOP WITH THE USE FLAGS! JUST STOP! ENOUGH ALREADY! Raster, The fix for that is for ebuild maintainers to actually write ebuilds properly. It's not a slap-dash-chuck-it-all-together-and-whoopee! task, just like your job isn't like that. Example, the directfb stuff - that should be filtered out in the platform profile. How many x86 boxen have directfb installed? Auto- enable it in USE for an embedded system where it is appropriate. I use vapier and barbieri's ebuilds. They are sane, never had a problem with them since '07 or thereabouts. The problem isn't gentoo, or portage. It's wankers publishing ebuilds without having a clue first. Tell those wankers to shove right off by all means. Or even put a big <blink><red> notice on the web site saying you don't support gentoo, users need to talk to their ebuild maintainer. Just please don't rip out the useful compile config options. I like them, I rely on them, I'll be seriously pissed if you remove them because you got pissed with some wankers who don't have much clue. rant over :-) -- alan dot mckinnon at gmail dot com ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ enlightenment-users mailing list enlightenment-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-users
