On Wed, Oct 10, 2012 at 10:33:30AM +0100, Stefan Schmidt wrote: > Hello. > > On 10/10/12 10:17, David Seikel wrote: > > On Wed, 10 Oct 2012 10:00:54 +0100 Stefan Schmidt > > <s.schm...@samsung.com> wrote: > >> > >> 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: > > > >> 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 suspect packagers would rather have it my way as well. Less work for > > them to do if it just detects what needs to be built. They also have > > strictly controlled environments. Then they only have to worry about > > making sure the dependencies are there, and not have to worry about > > figuring out more options as well. Which is their job. > > I did some packaging for embedded stuff and I hated it. But it seems we > both did not do packaging for desktop distros (correct me if I'm wrong > for you here). Any packagers around that can shed some light on this? > You guys like autodetection? Hate it? Don't care?
I maintain meta-efl layer in openembedded and in general we hate autodetection. Only way to have reproducible builds is to add "optional" dependency D as hard dependency, otherwise if there is some other package (completely unrelated to efl) which needs the same D, then rebuilding efl package later will detect D available and change the output without any metadata change. Cheers, > > As for the rest, most people expect to just do "./configure && make && > > sudo make install" or something equivalent, then have it autodetect > > what it can work with. That's kinda a major point of autofoo. > > Autodetect to support the right thing on different systems: Good > Autodetect and fail to build evas png loader because libpng-dev was not > installed and thus fail on loading a theme: Bad > > I have seen a fair amount of trouble regarding "successful" builds but > failures on runtime due to missing loaders. As we moved the librsvg > based loader to evas modules it showed up on mass again. > > I'm an explicit guy not an > implicit-guess-what-I-mean-with-this-in-this-context gyus :) > > Anyway, my opinion is as good as yours and I made my point here. Lets > see what others think. > > regards > Stefan Schmidt > > ------------------------------------------------------------------------------ > 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 -- Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: 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
