Carsten Haitzler (The Rasterman) schrieb: > On Wed, 10 Oct 2012 21:52:30 +0200 Thomas Sachau <to...@gentoo.org> said: > >> Tom Hacohen schrieb: >>> On 10/10/12 11:11, Stefan Schmidt wrote: >>>> Hello. >>>> >>>> On 10/10/12 10:04, Tom Hacohen wrote: >>>>> On 10/10/12 11:00, Stefan Schmidt wrote: >>>>>> Hello. >>>>>> >>>>>> On 10/10/12 09:50, David Seikel wrote: >>>>>>> On Wed, 10 Oct 2012 09:37:00 +0100 Stefan Schmidt >>>>>>> <s.schm...@samsung.com> wrote: >>>>>>>> Image loaders are way more complicated sadly as we drag in >>>>>>>> dependencies here. I would vote for making jpeg, png, gif, bmp, eet >>>>>>>> on by default. >>>>>>>> >>>>>>>> For the others we might need to see what libs distros ship in a >>>>>>>> default installation so we can decide if we have a hard dep on these >>>>>>>> libs or not. >>>>>>> >>>>>>> Better would be to remove the options, but detect them at build time to >>>>>>> see if they should be included. Things should never be hard >>>>>>> dependencies, unless they actually are. >>>>>> >>>>>> I see that you don't want to have this for your embedded project. :) >>>>>> >>>>>> But I disagree here. Autodetection is even worse in the case for the >>>>>> image loaders as your application will fail during runtime to load a >>>>>> theme or display thumbnails, etc. In your strictly controlled env this >>>>>> is not a problem as you can only blame yourself but in my opinion this >>>>>> is a no-no for almost all other users. Thus I would vote against >>>>>> autodetection and choose the hard deps carefully to fit the majority of >>>>>> our users. >>>>> >>>>> I'm also against autodetection. I prefer strict option setting. But you >>>>> want to have them (all?) on by default and just let people disable them >>>>> if needed. >>>> >>>> This would defeat the original purpose of removing options, right? :) >>>> >>>> regards >>>> Stefan Schmidt >>>> >>> >>> I think the ideas is to remove useless options, not useful. :) >>> I'm not really against it, I'm fine with automagically detecting stuff >>> if packagers don't find this annoying, the real question is: do they? >> >> Of course they do. automagic does mean, that you cant control, what >> actually happens, so you will never know, what a specific package will do. >> >> Just a basic example: >> >> Optional dependency installed, automagic package sees it, uses it, but >> user/developer/packager does not notice it, later the optional >> dependency gets removed. The result: broken automagic package and no way >> to properly fix this. > > for someone doing rpm pkging... you should know that this wont happen because > rpm does auto deps... it ldd's everything looking for deps. >
As you can see in my sig, i do work on Gentoo Linux and until now, i dont create rpms but instead ebuilds, so this is no valid point. ;-) Beside that, it is also a valid point for creation of rpms, since the list of dependencies and features will then change, always depending on the currently installed list of optional dependencies of the packager. So if someone starts with a minimal system, he will have all optional features disabled, and a new build of the package later on with more optional packages installed would create a different result, since it includes more optional features and more dependencies. So again someone would have to check the build system itself for optional automagic dependencies, install them all before building packages for efl, just to be sure to always have the same result. And again, just forcing those dependencies would make it much easier for the packager, since the result does not vary depending on the current set of installed optional dependencies. So again: Either force-disable/force-enable a feature or allow configure switches for it, automagic just causes more confusion and more work for packagers and users. -- Thomas Sachau Gentoo Linux Developer
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
