On Thu, 24 Dec 2015 11:10:30 +0100 Boris Faure <bo...@fau.re> said: > On 15-12-15 11:13, Carsten Haitzler wrote: > > On Mon, 14 Dec 2015 21:41:04 +1030 Simon Lees <si...@simotek.net> said: > > > > > Now waiting for the script that auto changes the flag whenever the > > > gentoo wiki gets updated > > > > we need to get more imaginative then. :) > > > What is the intent behind that? > What's the point in pissing off people (myself included) ?
thhe point is that an option is enabled or disabled that is not recommended. then someone complains of "my build broke" or "this doesn't work". and we have to field endless questions only to find out it is this problem. so as in the past, a gentoo user turned up and complained his ebuild is broken. i ask "did you enable/disable x/y/z?" the answer: "i don't know - i just copied the ebuild and didn't look - i don't know what that option even means, but it's a use flag" etc. etc. you can blame the gentoo user mentality of "omg. i need to customize every possible option if it at all exists, and i won't read any docs on it or what it does or how it works or interacts with the codebase". this is why that option is there to begin with and why it gets changed - it's to try and force whoever is maintaing the build to sit and think for a bit about what they are doing and possibly re-evaluate their choices and be reminded that what they are doing is likely problematic. you are not the target for this, but reality is that there isnt' another way to address the issue. if we make it an environment variable that bypasses the need for this option "only for advanced people" then ebuilds just eventually have that embedded into them without anyone knowing why: "just set this and you never have to deal with that option again". once every year or 2 this option may change. is that THAT much of a burden for you? > Now I have to change my script since I disable pulseaudio, physics and > gstreamer. Yes, I do send patches when things break. > Do we really have the luxury to piss off maintainers when we look at > the state of the packaging in various distributions? Debian is far > out-dated it's not even funny, even arch did update to efl-1.16 just a > week ago and stayed way too long with 1.15.1 while 1.15.2 was out and > fixed a bug reported few times about terminology's settings panel. > If you just want not to waste your time on bugs from people who used > that option, just do like the linux kernel does with the "tainted" flag. > Pissing off people is not the way to do. You just look arrogant. You're > just throwing a wrench into the gears of people who try to port efl to > not supported platforms like windows, mac, the *BSD… and how do you know it's tainted? you expect every efl app to print some error debug? or you expect an invisible "this is tainted" log on build? do you know that people don't even READ their logs? they pastebin them and let us read them for them? when they clearly state something like "cannot find pkg x between version Y and Z". they never read a log even when a build fails, let alone when it succeeds. and most of them never have or keep the logs, so it's runtime then... package maintainers HAVE to update their build files when they update a package. this option and it changing has NOTHING to do with the lack of packages. they have to change version number, probably changelog, and quite possibly the file include list if we added new install files and they were very strict on their package file lists. proper packaging requires this. so you got angry because a build failed and you have to change 1 char in the options? billiob. i thought better of you. that option exists because many options are untested, or experimental or buggy. example - xcb. i know for certain it does not fully implement every ecore-x function. in some cases we actually cant implement with xcb. this option changing serves as a reminder that making these kinds of options ... an option and changing them is dangerous leading to a broken system. if we don't do this, those that have far less clue than you simply never know because they blindly use some build script and swizzle options THAT script tells them they can with no warning. it's not arrogance - it's trying hard to help those tho don't know any better - to really point out the advice that their options may be problematic. the other option is we remove all build options that are untested or supported. then we can't have any "bad builds" and then people like you have no option but to patch the src code or go away. i have seriously considered this many times but chose to keep at least the most useful options so people like you can make the choice. you don't think that this small bit of work on your part is not worth the ability to have the option to disable pulse audio for example? (disabling the support disables audio support in edje and that then means that a whole edje feature doesn't work as advertised. YOU know this and accept that - but do others who don't even read the README and make an informed decision?) > /me got angry > -- > Boris Faure > Pointer Arithmetician -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
