From owner-freebsd-ports@FreeBSD.ORG Tue Aug 15 18:38:01 2006 Return-Path: X-Original-To: freebsd-ports@FreeBSD.org Delivered-To: freebsd-ports@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D348816A4DE; Tue, 15 Aug 2006 18:38:01 +0000 (UTC) (envelope-from jhein@timing.com) Received: from Daffy.timing.com (ns1int.timing.com [206.168.13.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC1E343D5C; Tue, 15 Aug 2006 18:37:57 +0000 (GMT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (gromit.timing.com [206.168.13.209]) by Daffy.timing.com (8.13.1/8.13.1) with ESMTP id k7FIbpcO012235; Tue, 15 Aug 2006 12:37:51 -0600 (MDT) (envelope-from jhein@timing.com) Received: from gromit.timing.com (localhost [127.0.0.1]) by gromit.timing.com (8.13.6/8.13.6) with ESMTP id k7FIbpvQ047537; Tue, 15 Aug 2006 12:37:51 -0600 (MDT) (envelope-from jhein@gromit.timing.com) Received: (from jhein@localhost) by gromit.timing.com (8.13.6/8.13.6/Submit) id k7FIbpXH047531; Tue, 15 Aug 2006 12:37:51 -0600 (MDT) (envelope-from jhein) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17634.5246.887894.836856@gromit.timing.com> Date: Tue, 15 Aug 2006 12:37:50 -0600 From: John E Hein To: =?UTF-8?B?R8OhYm9yIEvDtnZlc2TDoW4=?= In-Reply-To: <44E194BA.2020507@FreeBSD.org> References: <20060814234414.GA57035@hades.panopticon> <44E194BA.2020507@FreeBSD.org> X-Mailer: VM 7.19 under Emacs 21.3.1 X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on Daffy.timing.com X-Virus-Status: Clean Cc: babak@farrokhi.net, amdmi3@mail.ru, freebsd-ports@FreeBSD.org Subject: Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?] X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Aug 2006 18:38:01 -0000 G=E1bor K=F6vesd=E1n wrote at 11:32 +0200 on Aug 15, 2006: > Dmitry Marakasov wrote: > > Now, I think the way DESTDIR-related changes were done to bsd.port.m= k is > > absolutely wrong. For example, X11BASE, LOCALBASE, DATADIR now conta= in > > DESTDIR. But, these variables are frequently used when changing path= s > > hardcoded in port's sources (see many of my ports, for example > > games/fishsupper: > > > > @${REINPLACE_CMD} -e 's|data/|${DATADIR}/|' ${WRKSRC}/src/getreadydi= splay.cc > > > > After change, all these ports will not support DESTDIR automatically= =2E > > Incomplete list of such ports: > > > > find /usr/ports -name Makefile -exec grep -E \ > > "REINPLACE_CMD.*(DATADIR|LOCALBASE|X11BASE)" {} > > > > Now, if we want to fix these, we'll need to change variables in > > REINPLACE_CMD lines: LOCALBASE to LOCALBASE_REL, X11BASE to X11BASE_= REL > > and DATADIR... hmm, we have no DATADIR_REL, so all is left is > > ${PREFIX}/share/${PORTNAME}. That's unforgivable. > > Yes, that's right as well, but note if we had left LOCALBASE, LINUXBAS= E, = > X11BASE unchanged, we would need to change them in the *_DEPENDS lines= =2E = > That's true that we don't have DATADIR_REL, etc. We could introduce th= em = > if needed, but that substitution can be done with make :S as well. = > DESTDIR implementation is complicated in many ways, no perfect = > implementation exist. As you said LOCALBASE is used in substitutions, = bu = > also used in *_DEPENDS as well. Now those two cases have to be = > distinguished. One of them should have been changed at all... That's w= hy = > I say no perfect implementation exist. If we implement new functions = > later, it can be very difficult... I haven't followed any of this thread, so I apologize for rehashing anything that's already been beaten to death. First comment: MOST of the time people should be installing to ${DESTDIR}${PREFIX} (aka ${TARGETDIR}) anyway rather than ${DESTDIR}${LOCALBASE}. If anyone is using LOCALBASE for installs rather than PREFIX, in most cases, that is wrong. If you install directly to LOCALBASE, you are no longer PREFIX clean. Second comment: the way DESTDIR was hacked into bsd.port.mk from the beginning was wrong (/usr/share/mk/*.mk treats it correctly). We could either accept that as it has been for a long time or try to fix it. Once you accept that the longstanding usage of DESTDIR in ports is bogus, then you need to think about how to fix it. Unfortunately, individual ports (port writers) need to be aware, to some degree, about the proper meaning of DESTDIR. Until all third party software uses the same method to build and install their software (never), not everything can be fixed in bsd.port.mk. Now, let's take LOCALBASE. You could have a version of LOCALBASE (1) that has DESTDIR in it. You could have another version without DESTDIR (2). You need to use the right one at the right time (general rule: anything to do with installing needs DESTDIR; anything at build time or run time doesn't; the complicated part comes in when you are trying to build a package - some places need DESTDIR, some don't - the pkg* tools could be fixed to understand DESTDIR better, but that's another story altogether). In my original patch (ports/28155), I chose to have (1) called ${DESTDIR}${LOCALBASE} and (2) called LOCALBASE. This would allow a certain class of uses of LOCALBASE to remain unchanged... but not all. G=E1bor chose to have (1) called LOCALBASE and (2) called LOCALBASE_REL. Fine. This allows a different class of uses of LOCALBASE to remain unchanged... but, again, not all. You could call (1) FOO and (2) BAR. That would require LOTS of changes, of course. You could also call (1) ${LOCALBASE:C/^/${DESTDIR}/} and (2) LOCALBASE. And so on and so on. Which method requires the fewest changes to individual ports is an exercise for the reader. But the difference is probably not consequential enough to worry about. The hard part is to get ports writers to think the right way about DESTDIR after ignoring it for so many years. And once you decide to go about fixing it, there's no way around that problem. > > What I propose is: > > - Change variable naming scheme. > > All *BASE and *DIR vars should be reverted to their original meaning= s > > (i.e. local paths). Instead, INSTALL_ vars should be introduced: > > INSTALL_LOCALBASE=3D${DESTDIR}/${LOCALBASE} > > INSTALL_X11BASE=3D${DESTDIR}/${X11BASE} > > INSTALL_PREFIX=3D${DESTDIR}/${PREFIX} > > INSTALL_DATADIR=3D${DESTDIR}/${DATADIR} I understand where you're coming from, Dmitry. It's one way to do it. It's more like my original way. I chose to not name that variable at all, however - individual ports would just call it ${DESTDIR}${LOCALBASE} (or more correctly ${DESTDIR}${PREFIX} in most situations). You may think it's the better way. It may be that someone performs the exercise I mentioned above to count the number of changes one way requires vs. the other way and finds it to be the case. That said, I think G=E1bor is open to alternate ways to do things to some extent (he does have an SoC deadline for the current hunk of work). He's been quite reasonable in responding to my comments. If you can come up with a patchset (to Mk/* and maybe a couple ports) and show that it requires substantially fewer changes to individual ports, by all means, send it along. Whether one is better is largely a matter of taste, IMO. As I said, the bigger issue is just making people DESTDIR aware after so many years. I suspect portlint can be a helpful tool in this regard. > > * I don't think DESTDIR compatibility can be tested automatically Lots of aspects can be tested automatically, quite easily. Not port-specific stuff, of course. Finally, I'd like to say thanks to G=E1bor and the ports team for picking this up. It's been a long time, and I had given up on having DESTDIR fixed (relying on local workarounds for installing ports for local disk/product builds). I thought I might be the only one who cared. When I sent the original PR, I didn't think too much about a number of aspects (like the interaction with PKG_DBDIR files). I didn't treat the DESTDIR area as a chroot. It was just a start to fixing the biggest problem: getting DESTDIR out of PREFIX. That may be why it was never picked up - it was just a start. G=E1bor has considered this stuff a good bit more, and I appreciate the work he's done. It's a good beginning to fixing a pervasive problem. It may evolve to something even better.