Date: Thu, 26 Mar 2015 19:09:27 +0100 From: Guido Falsi <madpilot@FreeBSD.org> To: Michelle Sullivan <michelle@sorbs.net> Cc: freebsd-ports@freebsd.org Subject: Re: net/unison240 depends on lang/ocaml-nox11 Message-ID: <55144B57.50301@FreeBSD.org> In-Reply-To: <551442B6.7020708@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> <55140F34.3090304@FreeBSD.org> <551442B6.7020708@sorbs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03/26/15 18:32, Michelle Sullivan wrote: > Guido Falsi wrote: >> On 03/26/15 12:59, Michelle Sullivan wrote: >> >>> Guido Falsi wrote: >>> > >> 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) It all boils down to one simple concept: All the tools at present are coded with the knowledge that "foobar-nox11 != foobar" (or "foobar-baz != foobar", in general). This is an assumed thruth in the logic. I'ts like a postulate. You propose to change the postulate, which would require a radical change to the whole structure. Personally, while pkgng isn't perfect, I find it really really useful and it really lowers management load for me, even though it requires some overhead it's much better than the old pkg tools. I find it not worse than other OSes package management tools, in some respect definitely better. poudriere+pkgng+binary-updates has limitations and requires continuous care for poudriere configuration. Using no package manager or a less strict one gives more freedom but that has a cost as well, old pkg system was a nightmare of untracked files, leftovers, and corrupt /var/db/pkg. > >> 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. OPTIONS_SET_FORCE/OPTIONS_UNSET_FORCE are the way to go, with those you don't risk overriding with a per port option. Just put them all together in one place where you can check them easily and fast in case of something going wrong. >> >> 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. It may be special for a user, but there isn't really any special handling in the infrastructure for it. It's up to the ports themselves. It's a flag like any other, and from a programmer point of view this is a very good thing :) > >> 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.) that would require again poudriere to know that ocaml-nox11 is in some way related to ocaml and make an informed decision based on such knowledge. But the tools have no such knowledge and make no such assumption. They simply see two different strings in package name, which is assumed to be unique, so they must be different packages. While the outcome of an informed decision looks simple enough for the unison case it's not so clear cut in most other cases and would require very specific knowledge of each package and the context of the system on which the package will run. I think that such information and decision making belongs to the system administrator. I'd hate a build system which interpreted my flags and did things it's way, I'd rather get a failure and an error message. Bonus points if the error message is clear and helpful :) > >> 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) Again ocaml != ocaml-nox11. They look similar to humans, but for the systems are two different things and that's intentional. > > 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.... At present it is quite possible to build ocaml WITH X11 and unison without it even in poudriere, just don't use the global OPTIIONS_UNSET=X11, but use per ports flag, with X11 enabled for ocaml and unset for unison. Poudriere will do the correct thing, you just have to tell it what you want it to do. -- Guido Falsi <madpilot@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55144B57.50301>