Date: Wed, 30 Apr 2008 03:05:14 -0400 From: "Aryeh M. Friedman" <aryeh.friedman@gmail.com> To: David Wood <david@wood2.org.uk> Cc: Jim Stapleton <stapleton.41@gmail.com>, Alexander Ryba <ryba@sylow.cs.qc.cuny.edu>, ports@FreeBSD.org, Jacobus Geluk <jacobus.geluk@gmail.com>, Simon Barner <barner@FreeBSD.org>, Jeremy Messenger <mezz@FreeBSD.org> Subject: Re: Is someone already working on a port that supports Boost 1.35.0? Message-ID: <48181A2A.1000303@gmail.com> In-Reply-To: <KsaSHhOu3AGIFA51@wood2.org.uk> References: <b1ff6f240804250756u483501acyc5a5527bb4b489eb@mail.gmail.com> <20080429184420.GB5010@dose.local.invalid> <48178247.2010008@gmail.com> <20080429212721.GA5795@dose.local.invalid> <4817D91E.1040900@gmail.com> <KsaSHhOu3AGIFA51@wood2.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am top posting because my comments are general and not in relationship to any given point. I think Mezz along with Simon both the right way to handle it for now. There are several projects that I am not directly involved designed to tackle this sort of issue with ports 2.0 being the right long term solution but not needed to solve this issue per se so I will not discuss it here. Most of the projects can be found on Ale's PortsToDo wiki (wiki.freebsd.org/PortsToDo) the main one not found on there is Jim Staplton's virtual ports DB (which I think is either in the committ queue or should be since both me an Ale have signed off on it as being a good idea). The issue is really not the infrastruct as you state but the more patchs like this we make the more likely it is the infrastruct will become problematic down the road. David Wood wrote: | Dear Aryeh and all, | | In message <4817D91E.1040900@gmail.com>, Aryeh M. Friedman <aryeh.friedman@gmail.com> writes |> Simon Barner wrote: |> |> | Yes, I am working on a port. I will send a message to freebsd-ports |> |> | once it is ready for testing. |> |> |> |> While your at it please make it so there is one boost port not boost and |> |> boost-python |> | |> | I will keep boost and boost-python in seperate ports in order to |> | keep boost as lean as possible. boost-python will no longer conflict |> | with boost but just add python support. The same applies for OpenMPI |> | and MPICH support. |> | |> | Simon |> | |> Have you ever examined the ports that actually use boost and boost-pyhton... it seems completely random sometimes which one is which (i.e. stuff that doesn't require pyhton often depends on boost-python and stuff that does depend on it relies on boost).... this leads to some really nasty conflicts and hard to resolve (unless you have done it before) ordering problems (if I build port A then B then B will fail because it wanted one flavor of boost when the other one is the installed one but if you do B then A then it works fine because A doesn't care what flavor of boost it is looking for).... the classic example of this is net-p2p/deluge and multimedia/miro where deluge wants python and miro doesn't care.... Since it is trivial to have a build/ruin depend on an OPTION (and you already do it via a gnob no more complexity it added by doing it as an OPTION)... Almost every time I have brought boost problems up the overwelming consenus among maintainers that relie on boost is two seperate ports is completely insane. | | boost-python is merely a slave port of boost that adds python support - it's not two separate ports. You can build boost with python support using the WITH_PYTHON knob. | | | At the moment, it really has to be this way because you can't USE_PYTHON= yes after including bsd.port.pre.mk - but that's exactly what you'd need to have python as an option. This is why there's the slave port - or the WITH_PYTHON knob - so that the python dependency is dealt with before including bsd.port.pre.mk. The only way around this at present would be to change bsd.python.mk so that it could be set after bsd.port.pre.mk. | | One of the ports I maintain, net/freeradius, uses an ugly hack that I inherited and would not have written. net/freeradius2 has the hack removed because FreeRADIUS 2 includes rlm_python in the default configuration, so it always depends on python. | | | My mind is a little hazy this early in the morning, but I believe we're only a month away from being able to use Mk/bsd.options.mk, as all FreeBSD versions that lack the necessary support in the underlying OS go EOL on 31 May. That will solve this problem, as you'll be able to call bsd.options.mk before bsd.port.pre.mk, and will therefore be able to include bsd.python.mk based on OPTIONS without bsd.python.mk being rewritten. | | Unless there's any last minute extensions, the only versions of FreeBSD that are supported after 31 May will be 6.x from 6.3-RELEASE onwards, 7.x from 7.0-RELEASE onwards and 8-CURRENT. 6.1-RELEASE and 6.2-RELEASE both become End of Life on 31 May, as does RELENG_5 and all 5.x-RELEASEs. | | | However, there's a deeper issue here - and it's IMHO not about the infrastructure, but about user choice versus the difficulties of dependency with 18000 or so ports. To that end, please don't make this into a discussion about "Ports 2.0", Aryeh - at least not from the starting point that the current infrastructure causes this problem. I'm not saying that the current infrastructure is perfect, or that there's no scope for improvement. Rather, I don't see how any infrastructure changes could, by themselves, resolve the conflicting issues here. | | When there's a fairly heavyweight option in a port, such as python support, and other ports need to depend on the "with python" version of that port, things can get a bit tricky. | | Clearly, any ports that do rely on the python version need to depend on the "with python" version. Those that don't rely on python support in that port should depend on either version (which is one situation where slave ports are useful - you depend on the master port and don't care about the state of the option or knob). That way, if you need to add python support of the depended upon port later, it's a case of substituting the "with python" version, maybe using portmaster or portupgrade with -o. | | The difficulty when you need to depend on the "with python" version can be writing the test for LIB_DEPENDS / RUN_DEPENDS / BUILD_DEPENDS, bearing in mind that you only have the equivalent of ldconfig -r | grep ... for LIB_DEPENDS or test -e / which -s available to you for RUN_DEPENDS / BUILD_DEPENDS. It's not always easy to test via these mechanisms for a particular option or knob in a port you are depending on - sometimes the best that can be done is to test separately and return an error, ideally giving a suggested fix to the user, if the necessary support isn't found. | | | Surely it should be the user's right to choose wherever possible whether a port includes or excludes certain support. Adding an extra dependency on a complex piece of code such as OpenSSL or the Cyrus SASL library arguably increases the security risk of running that port, as well as introducing possible extra maintenance overhead. | | Not every system has plenty of spare storage space and processor power, either. My new FreeBSD server is a dual Xeon E5430 (a total of 8 cores at 2.66GHz) with 8GB of RAM, though my current production box is a rather more modest Pentium III 733MHz with 512MB of RAM. There are many running FreeBSD on very modest embedded boards, including users of firewall distributions such as pfSense. Of course, even 'big iron' like my dual Xeon box doesn't necessarily have processor power to waste! | | | I'll leave it there - I'm sure many here are familiar with all the issues in this sometimes difficult area of dependency, often from both sides of the fence as ports maintainer / committer and as user. | | | Best wishes, | | | | | David -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgYGioACgkQk8GFzCrQm4B4vgCdFFCSLf2uiRENPgEVqt7Zybju OzMAoIcPRfVfiLCksEr/4wmXwIup0Iuy =PMwp -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48181A2A.1000303>