After having read these mails, as well as the past mails on this topic, I'm beginning to see a pattern.
This option was originally implemented because a Gentoo user came into #e last year asking why something in Enlightenment didn't work (possibly mouse cursors, since the eet image loader is/was optional). It was determined that changing any "default" configure option would require this flag so that Gentoo users would then come to #e to ask why their ebuild was broken instead of lacking features in their applications. Having seen the flag at work for almost two years, I can only say that, in my opinion, the objective has not been met. Trying to filter Gentoo users (since yes, it was directed specifically at blocking them from toggling features) in this way is, in a word, impossible. To understand why, it's necessary to examine the state of Enlightenment packaging in Gentoo. Currently, Gentoo "provides" Enlightenment. Looking at the available packages (https://packages.gentoo.org/packages/x11-wm/enlightenment https://packages.gentoo.org/packages/dev-libs/efl), it's easy to see that updates are not frequent since none of the packages are even close to up-to-date. Users can easily figure out what the latest version of available software is, and they will typically want to use it, even more so on Gentoo. So how do Gentoo users usually install Enlightenment to get these latest versions? They use third party repositories. Checking the list of (public) repositories for Enlightenment packages yields significantly more results ( http://gpo.zugaina.org/x11-wm/enlightenment http://gpo.zugaina.org/dev-libs/efl). These repositories are maintained by users (anyone), and are updated MUCH more frequently than the core repository, typically by someone who is more in-tune with upstream development. According to the overlays listed, none have yet updated to the flag's name change, but I'd guess this is more likely related to lack of time due to holidays/end of year than not having noticed the change or having been notified of it. Regardless, once they update, and they will, breaking this option will have been a waste of time for everyone, including the time that I spent writing this mail. Furthermore, I'd like to address what may be an oversight from the statement that "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" from Carsten. I think the fact that all the ebuilds contain the previous flag, specifically the updated version, indicates that either nobody is reevaluating anything here or nobody cares. So, in effect, all that's happening here is that we're annoying everybody else permanently so that we can annoy Gentoo users for a period of a couple weeks after changing the flag. I'm not affected by this personally, but I don't think this makes promoting our projects any easier. Given the size of our userbase, I'd have expected us to be working harder to make things easier for anyone and everyone to use our code, not adding small speed bumps like this for people to potentially be affected by simply because eg. their system doesn't distribute a -devel package for Bullet. To me, perhaps a more user-friendly and packager-friendly approach would have been to pop an error in applications which use optional features about a feature being missing. While this puts a small burden on application developers, it's a much smaller overall burden than this configure flag experiment, which I can only view as a debacle. On Thu, Dec 24, 2015 at 8:34 AM Carsten Haitzler <ras...@rasterman.com> wrote: > 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 > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
