Date: Fri, 12 Oct 2018 13:03:16 -0600 From: Adam Weinberger <adamw@adamw.org> To: amdmi3@amdmi3.ru Cc: des@freebsd.org, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org, portmgr@freebsd.org, perl@freebsd.org Subject: Re: svn commit: r481365 - in head: archivers/p5-Archive-Any archivers/p5-Archive-Any-Plugin-Rar archivers/p5-Archive-Extract-Libarchive archivers/p5-Archive-Peek archivers/p5-Archive-Rar archivers/p5-A... Message-ID: <CAP7rwciqm1nBVWbnFXOqG%2BFfH8OO%2BCu_jH02utsfF7Bi-d_qeg@mail.gmail.com> In-Reply-To: <20181012174130.GF79805@hades.panopticon> References: <201810061306.w96D6jJe040138@repo.freebsd.org> <20181012174130.GF79805@hades.panopticon>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 12, 2018 at 11:50 AM Dmitry Marakasov <amdmi3@amdmi3.ru> wrote: > > * Dag-Erling Sm=C3=B8rgrav (des@FreeBSD.org) wrote: > > > Author: des > > Date: Sat Oct 6 13:06:42 2018 > > New Revision: 481365 > > URL: https://svnweb.freebsd.org/changeset/ports/481365 > > > > Log: > > Fix every instance of RUN_DEPENDS:=3D${BUILD_DEPENDS} in p5 ports, ex= cept > > for where it resulted in a change in output from build-depends-list o= r > > run-depends-list. > > > > Approved by: portmgr (adamw) > > What exactly is this `fixing'? This is explicitly stated in PHB 5.9.2 as > wrong: > > https://www.freebsd.org/doc/en/books/porters-handbook/makefile-depend.htm= l#makefile-run_depends > > > -BUILD_DEPENDS=3D p5-Object-Tiny>=3D0:devel/p5-Object-Tiny > > -RUN_DEPENDS:=3D ${BUILD_DEPENDS} > > +BUILD_DEPENDS=3D ${RUN_DEPENDS} > > +RUN_DEPENDS=3D p5-Object-Tiny>=3D0:devel/p5-Object-Tiny > > After this change, if something is added to RUN_DEPENDS, it'll end up in > BUILD_DEPENDS as well. This already leads to perl being mentioned in > BUILD_DEPENDS twice. > > Here's another example: > > % grep nmap /usr/ports/net-mgmt/p5-FusionInventory-Agent/Makefile > NETDISC_RUN_DEPENDS=3D nmap:security/nmap \ > > The intent is clearly for nmap to be added to run depends only. But: > > % WITH=3DNETDISC make -C /usr/ports/net-mgmt/p5-FusionInventory-Agent -V = RUN_DEPENDS | grep -o ' nmap' > nmap > % WITH=3DNETDISC make -C /usr/ports/net-mgmt/p5-FusionInventory-Agent -V = BUILD_DEPENDS | grep -o ' nmap' > nmap > > -- > Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D > amdmi3@amdmi3.ru ..: https://github.com/AMDmi3 With all credit to des, I'll give you how he explained it to me. While it isn't better in every circumstance, it is definitely better more often than it's worse. If there were instances where the change brought in incorrect dependencies, those should definitely be repaired (and please, do fix them!). <<EXPLANATION; The reason why R_D=3DB_D is bad is explained in the handbook. The reverse is safe because the only consequence of R_D leaking into B_D is that they are installed a little earlier. They must be installed before staging anyway. And =E2=80=9Canything I need to run, I also need to build= =E2=80=9D is very simple to grasp when reading the Makefile, once you get past the forward reference. Finally, and perhaps most importantly, the MY_DEPENDS idiom doesn't scale well with options; see my recent commit to textproc/p5-Plagger to understand why. If, at some point, the ports system is modified so that runtime-only dependencies don't need to be installed at all (which would be great news for metaports), then this will no longer be the case and the patched ports will be wrong =E2=80=94 but no more than before my patch. In= the meantime, we have 2,400 p5 ports setting a bad example for people who are more likely to copy-paste from an existing port than to read the handbook. If I might offer a suggestion, it would be to add a CORE_DEPENDS which is treated like the other _DEPENDS with respect to options etc., but is not affected by Uses or any other automagic. You could then list the intersection of B_D and R_D in C_D, and set B_D=3DC_D and R_D=3DC_D either explicitly in the Makefile (just like MY_DEPENDS in the example in the handbook) or implicitly in bsd.ports.mk. Various Uses etc. would then append to B_D and R_D in the usual fashion with no risk of either leaking into the other. EXPLANATION I personally really, really like the idea of just a DEPENDS=3D variable that does the actual right thing. # Adam --=20 Adam Weinberger adamw@adamw.org https://www.adamw.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAP7rwciqm1nBVWbnFXOqG%2BFfH8OO%2BCu_jH02utsfF7Bi-d_qeg>