graphics/php*-gd requires X11 by default
I sent an email to the maintainer of these ports (t...@freebsd.org) a few days ago, but didn't hear back - so I thought I'd raise the same question to the mailing list instead. --- Hey there! I was wondering something about the php-gd ports (specifically 7.2 but earlier as well). Looking at the config options I see this: X11=on: Enable XPM support With this option enabled php-gd can read XPixMap images, but in turn this pulls in a host of additional X11 dependencies. That's an awful lot for (usually) headless servers, especially for an image format that is (relatively) unused. I don't mind the option being there but because it is defaulted to "on", that means official FreeBSD packages are built with this support and all the dependencies. On my system I have to manually build this one port just to turn off the option. Would it be possible to modify the defaults for this port so that X11=off by default? Or, why is the default to "on"? (I have a guess, that this respects WITHOUT_X11 in /etc/make.conf, but that's useless for pre-built binary packages) -Greg ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: how to enforce one version of python
tech-lists writes: > > _This_ is really annoying. I try to keep my systems with exactly > > what they need installed, to reduce both bloat and possibly security > > issues. > > YES. This for me is *exactly* why it is so infuriating. And > doubleplus regarding security. Followed closely by something > installing the py-27 version when I wanted the 36-version. > > I'd like to have the latest stable python for everything that > requires it. Like I have with perl. I think that means py-36. I > don't want py-27. I'd like to enforce that, but seemingly I can't, > because the invocation in make.conf for default version does not > enforce it in all situations. > > If something wants another version of python, I want it to fail, > ideally spitting out a usable reason why. Is my position > unreasonable? I hope it isn't. Maybe it is? I dunno. Let's see if the folks on python@ have better information. Respectfully, Robert Huff ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: how to enforce one version of python
On 13/09/2018 17:39, Robert Huff wrote: _This_ is really annoying. I try to keep my systems with exactly what they need installed, to reduce both bloat and possibly security issues. YES. This for me is *exactly* why it is so infuriating. And doubleplus regarding security. Followed closely by something installing the py-27 version when I wanted the 36-version. I'd like to have the latest stable python for everything that requires it. Like I have with perl. I think that means py-36. I don't want py-27. I'd like to enforce that, but seemingly I can't, because the invocation in make.conf for default version does not enforce it in all situations. If something wants another version of python, I want it to fail, ideally spitting out a usable reason why. Is my position unreasonable? I hope it isn't. Maybe it is? I dunno. thanks, -- J. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: emulators/i386-wine-devel
On Saturday, 01 September 2018 22:45:58 SAST Rozhuk Ivan wrote: > Hi! Hi > What happen with emulators/i386-wine-devel ? Honestly, I've lost interest in compiling the port. I'm working on a means to avoid manual compilation [1][2]. I've attached the scripts I use to build and update the ports - if anyone is interested. > I use it on FreeBSD 11.2 x64 to run old win32 apps. The above mentioned work will also make running win64 apps concurrently with win32 apps. Regards [1] https://reviews.freebsd.org/D14721 [2] https://reviews.freebsd.org/D16830 signature.asc Description: This is a digitally signed message part.
