Date: Thu, 26 Mar 2015 14:52:52 +0100 From: Guido Falsi <madpilot@FreeBSD.org> To: Michelle Sullivan <michelle@sorbs.net> Cc: Jeremie Le Hen <jlh@FreeBSD.org>, Geoffrey Mainland <mainland@apeiron.net>, freebsd-ports@freebsd.org Subject: Re: net/unison240 depends on lang/ocaml-nox11 Message-ID: <55140F34.3090304@FreeBSD.org> In-Reply-To: <5513F487.4040105@sorbs.net> References: <CAGSa5y1ye0tAkF3Yjcd4yHA1_RjZxW025PaK3pexMChVW0c3eg@mail.gmail.com> <5507555C.7030508@FreeBSD.org> <CAGSa5y2h3T5RoEoGekJCHmRwS82hQHvhGTHpTVMHhcYM-e9awQ@mail.gmail.com> <5507F80F.70609@FreeBSD.org> <CAGSa5y1RTkoK7u1soQmMB9Sh_YEYe2hM1Hxfrf9LoOd3NF=Z%2Bg@mail.gmail.com> <55080F30.9010104@FreeBSD.org> <550B65A1.9080402@apeiron.net> <550DAD30.4080905@FreeBSD.org> <550DB13D.7020005@apeiron.net> <550DB247.2050800@FreeBSD.org> <20150326022129.GA7814@apeiron.net> <5513E5AD.8050103@FreeBSD.org> <5513F487.4040105@sorbs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/26/15 12:59, Michelle Sullivan wrote: > Guido Falsi wrote: >> On 03/26/15 03:21, Geoffrey Mainland wrote: >> >>> On Sat, Mar 21, 2015 at 07:02:47PM +0100, Guido Falsi wrote: >>> >>> Poudriere logs are posted here: >>> >>> https://zeno.apeiron.net/unison/test1/ >>> >>> With the config at the above link, poudriere won't even start a build >>> as it complains (rightly) about dependency conflicts. >>> >>> Removing lang/ocaml-nox11 from test.pklist gets the build to start, >>> but it ultimately fails because I have OPTIONS_UNSET=X11 in the >>> make.conf. You can see the logs from this failed poudriere build here: >>> >>> https://zeno.apeiron.net/poudriere/build.html?mastername=test-9-amd64-git&build=2015-03-25_22h09m00s >>> >>> The successful poudriere build, with the above patch to unison, is here: >>> >>> https://zeno.apeiron.net/poudriere/build.html?mastername=test-9-amd64-git&build=2015-03-25_21h34m02s >>> >>> I would like a way to have ocaml and unison, both X11-free, as I am >>> running on a headless machine. That used to be possible, and still is >>> if I patch unison as shown above. >>> >> >> Looking at this data I'd say you are trying to use an incorrect config: >> >> You don't need to specify both the unison-nox11 port and the ocaml-nox11 >> port in the list of ports to be built. >> >> Having OPTIONS_UNSET=X11 in make.conf you could ask for just net/unison >> and poudriere, respecting the OPTIONS_UNSET will build both unison and >> ocaml without any X11 support. In such a case you'd have a unison >> package, not stating it is not supporting X11 but in fact it will have >> no X11 binaries (this can be verified by looking into the package, which >> is just a txz archive) >> >> You can also request poudriere to build only net/unison-nox11, in such a >> case you end up with both packages with "-nox11" in their name. I think >> this is the best choice. >> >> you could also request poudriere to build both net/unison-nox11 and >> lang/ocaml and get the exact same result, but it is redundant, poudriere >> will anyway build ocaml from lang/ocaml, respecting the OPTIONS_USET. >> >> I can't apply your patch which would bring the port to be semantically >> the same as before my last modification, because it would break another >> legitimate and use, which is if you build any other port in the same run >> which asks for unison-nox11(which requires lang/ocaml-nox11 with your >> patch) and at the same time compiles some other ports depending on >> lang/ocaml. This would ensue a duplicate origin error, with no >> workaround for the user. >> >> You can see this situation as a limitation of the framework, if you >> like, but while there is an easy solution for you (just ask poudriere to >> build only unison-nox11 with OPTIONS_UNSET=X11 in make.conf and it will >> build and keep updated both unison-nox11 and ocaml-nox11), there is no >> solution for the duplicate origin, unless other ports are modified, >> which could also break even more things. >> >> > You know thinking about it - the problem is in poudriere - or more of > the way it builds depends, and that could be the way the ports framework > thinks about things... and possibly pkg.. This is beyond the scope of this thread. At present I can only make the unison port work in the widest possible array of configurations. Any request to modify pkgng or poudriere behavior should be directed at the appropriate mailing lists/maintainers. I'll reply below with my PERSONAL opinions about such requests. I reword it: the opinions below are personal and don't reflect the opinions of the maintainers of the mentioned tools(pkgng, poudriere) or portmgr or any other involved party in any way! > > My thoughts about the fix would be to have poudriere pick up the options > when installing pre-built depends and specifically with the global > 'unset' (which conflicts with the default 'set') have poudriere and/or > ports check for both ocaml and ocaml-noxll.... or on build pick up the > options of what is being depended upon... or remove the -nox11 suffix > completely (which would likely cause more issues.) > > unison shouldn't care which version of ocaml is installed.. unless X11 > is 'on' in which case ocaml needs to be compiled with X11 as well. In fact it does not, but, with the present versions of the tools and the state of the ports tree, considering the ocaml port changes it's pkgname depending on options, if I make unison have a conditional depend on ocaml/ocaml-nox11 it will trigger a multiple origin error in case another port depends on the othr flavour of ocaml. There no solution to this, except an overhaul of the ocaml port, perhaps, which has good chances of breaking other things. If, like I'm doing now, I just depend on lang/ocaml, so, if there are no conflicting flags in the environment, it works. It just needs a little attention from the poudriere user. > > eg: > > ocaml + unison = OK > ocaml-nox11 + unison = NOT OK > ocmal + unison-nox11 = OK > ocmal-nox11 + unison-nox11 = OK > > Now poudriere sees the global and local X11 unset options when computing > deps and builds as specified in the options, but doesn't account for > unison-nox11 wanting ocaml-nox11 but ocaml is ok... The solution (if It's problematic only since ocaml changes pkgname dynamically, but such a practice isn't forbidden by the rules at present. Changing the rules is possible but all of the ports tree needs to be checked for the consequences of such a change. Ocaml isn't the only port doing that, also. > possible) would seem to be tell unison that without X11 being set both > ocaml and ocaml-nox11 are valid dependencies and either are needed... > Of course that means the pkg manager needs to know this as well... which > neither pkg nor pkg_* can do.... though if in poudriere both can be > built so who cares? The solution then would seem to be to get unison to > request the dependency of ocaml-nox11 if X11 is unset in unison and > building in poudriere (can this be detected?).. or that the risk that > no-one would be stupid to ocaml-nox11 + unison (which a conflict of > ocaml-nox11* should solve) and therefore just test for ocaml is > installed by filesystem test and not via pkg test when building without > X11.... which would seem to be the solution to all of the above.... This would mean making the X11 flag special and add a lot of special knowledge about it all around. At present the tools just compare strings, ocaml-nox11 != ocaml. What you're asking for is a special case where ocaml-nox11 ~= ocaml. (with ~= meaning "sometimes equal to, if the conditions are right"). It can't be generalized to all -flag since in most cases you DO care, maybe your port really needs X11 support, or is crippled at ruintime even if it builds without that, or other obscure interaction. In fact unison too does care, since IF ocaml is built without X11 support unison itself cannot be built without. Even more obscure unison with X11 also depends on ocaml-lablgtk2, and this port too needs to be built with specific options for unison to work (GLADE or GNOMECANVAS, can't remember). Since I have no way of checking that I just "hope for the best". So, there's a lot of special casing to be done, in most cases requiring very specialized knowledge of each and every package. If you want to lobby for this kind of work done on the tools you're welcome, but I see it as impractical, also considering the fast moving target the ports tree is and needs to be, due to the continuous updates to it's leafs. IMHO such minute knowledge belongs to the administrator. The more complex and customized the system the harder the administrator's life. > unless I'm missing something. The other solution for may just be to > patch the ocaml Makefile from: > > OPTIONS_DEFAULT=X11 TK THREADS > > to > > OPTIONS_DEFAULT?=X11 TK THREADS > > Which if I understand the param correctly will change from always set > the defaults to X11 TK THREADS to set the defaults if there is no > previous config. No, that would not work. It simply says to make OPTIONS_DEFAULT=XXX IF OPTIONS_DEFAULT is undefined, but nowhere in the ports Makefiles if the OPTIONS_DEFAULT variable defined, and setting it arbitrarily in make.conf is definitely dangerous if many ports applied such solution. OPTIONS are taken from OPTIONS_DEFINE, and copied into PORT_OPTIONS depending on what is in the various OPTIONS_DEFAULT variables(which are read only from the ports Makefile prospective), what is defined in the OPTIONS_SET/OPTIONS_UNSET (also with the per port and FORCE variations) and the per port configuration in option directories, every factor with it's own priority. BTW there are: # OPTIONS_SET_FORCE - List of options to enable for all ports. # OPTIONS_UNSET_FORCE - List of options to disable for all ports. # ${OPTIONS_NAME}_SET_FORCE - List of options to enable for a specific port. # ${OPTIONS_NAME}_UNSET_FORCE # - List of options to disable for a specific port to be used in make.conf which are what you are looking for I think. If I remember correctly these will override the per port configuration in /var/db/ports (or poudriere equivalent in /usr/local/etc/poudriere.d). These flags do not solve the "problem" of the user setting them in a make.conf somewhere and forgetting about them, just to be bitten months later by some obscure problem caused by them. -- Guido Falsi <madpilot@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55140F34.3090304>