Date: Thu, 26 Mar 2015 18:32:38 +0100 From: Michelle Sullivan <michelle@sorbs.net> To: Guido Falsi <madpilot@FreeBSD.org> 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: <551442B6.7020708@sorbs.net> In-Reply-To: <55140F34.3090304@FreeBSD.org> 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> <55140F34.3090304@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Guido Falsi wrote: > 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. > I do not disagree with that statement in anyway - just exploring possibilities. > Any request to modify pkgng or poudriere behavior should be directed at > the appropriate mailing lists/maintainers. TBH Won't waste my time, because even if poudriere people looked at it I won't use 3.1 or above as it has issues in its own right that are unacceptable and not going to get fixed and any such patch wouldn't be applied to 3.0. > 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! > I understand your need to ensure they understand it's your personal view. :) > >> 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. Possibly... though if unison-nox11 is requested the options of ocaml is not necessary to change - so long as there is an ocaml installed - which comes down to poudriere requesting ocaml and falling back to ocaml-nox11 if it's not available (or more likely correct select ocaml-nox11 and fall back to ocaml if it's not available/built) > 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. > In my case my problem is solved - I just have 'UNSET_X11' in the global make.conf... which resolved the mistake of having 'UNSET_X11' in unison and no options set in ocaml... just trying to see if there is something more elegant so people really have to try to screw it up rather than screwing it up by omission. > >> 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. > I don't think that is a problem on the whole. > 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. > True and the promised changes to pkg (which like most bugs 'will be in the next version') is still not there... though I suspect they will find embedding the build options in the pkg will result in the same problems again, just at a different level (there isn't an easy solution.) >> 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. > In some ways it is.. perhaps one should have another 'Uses' for 'X11'... though thinking trivially about it, it will probably suffer in similar or more painful ways. > 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. > Sure? Think about unison (and other such packages where X11 can be turned off but depend on other packages that have -nox11 variants) ... unison doesn't care if X11 is off just whether ocaml or ocaml-nox11 installed so back to poudriere, for build_deps it should be able to request the -nox11 package and if it's not there retry for the package with x11 because both are valid dependencies (as an either-or) of unison-nox11 (only ocaml (with x11) is a valid dependency of unison though.) > 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". > Agreed but that's with x11... net/unison deps: ocaml+ocaml-lablgtk2(+others) net/unison-nox11 deps: ocaml-nox11 or ocaml+ocaml-lablgtk2(+others) > 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. > Not necessarily (note: necessarily - means I think there *may* be a solution - but whether thats possible/acceptable only discussion would be the key) For example, the pkg installation process instead of picking up an automatic dependency of ocaml of unison-nox11 any pkg installation would abort and tell the admin that ocaml would need to be installed first as there are 2 matching packages possible (or just prompting for which one to get/install) - unless one of the valid ones is already installed.. because something else may have installed ocaml already and may need the with x11 version. This is one of the major problems I have with packaging systems such as pkg and why I preferred (and still use) the old one. You setup the dependency, and you run into a problem of not being able to install what you want. eg: You might want unison-nox11 and another package also dependent on ocaml with x11 on the system... also if you don't want any x11 support on the system you end up with ocaml with all the x11 overhead as soon as you install unison-nox11 because that's what's in the package tree (unison-nox11 depended on ocaml instead of ocaml-nox11)... and then when you fix that you end up with a problem if you install packages in the reverse order.... > 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. > Thanks for clarifying. (and listening) Regards, -- Michelle Sullivan http://www.mhix.org/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?551442B6.7020708>