From owner-freebsd-ports@FreeBSD.ORG Tue Aug 15 12:36:10 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 8BA2D16A4E2; Tue, 15 Aug 2006 12:36:10 +0000 (UTC) (envelope-from amdmi3@mail.ru) Received: from mx2.mail.ru (mx2.mail.ru [194.67.23.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41D5B43D73; Tue, 15 Aug 2006 12:36:09 +0000 (GMT) (envelope-from amdmi3@mail.ru) Received: from [213.148.29.33] (port=1302 helo=nexii.panopticon) by mx2.mail.ru with esmtp id 1GCy9P-000PG7-00; Tue, 15 Aug 2006 16:36:07 +0400 Received: from hades.panopticon (hades.panopticon [192.168.0.2]) by nexii.panopticon (Postfix) with ESMTP id 756A617046; Tue, 15 Aug 2006 16:35:34 +0400 (MSD) Received: by hades.panopticon (Postfix, from userid 1000) id 2F7F8430B; Tue, 15 Aug 2006 16:36:12 +0400 (MSD) Date: Tue, 15 Aug 2006 16:36:12 +0400 From: Dmitry Marakasov To: G??bor K??vesd??n Message-ID: <20060815123612.GA52489@hades.panopticon> Mail-Followup-To: G??bor K??vesd??n , freebsd-ports@FreeBSD.org, babak@farrokhi.net, John E Hein References: <20060814234414.GA57035@hades.panopticon> <44E194BA.2020507@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <44E194BA.2020507@FreeBSD.org> User-Agent: Mutt/1.5.12-2006-07-14 Cc: babak@farrokhi.net, John E Hein , 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 12:36:10 -0000 * G??bor K??vesd??n (gabor@FreeBSD.org) wrote: > >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, LINUXBASE, > X11BASE unchanged, we would need to change them in the *_DEPENDS lines. > That's true that we don't have DATADIR_REL, etc. We could introduce them > 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 why > I say no perfect implementation exist. If we implement new functions > later, it can be very difficult... I don't quite understand what problems with _DEPENDS will there be, as DESTDIR can always be prepended to path when checking depends. > >Please tell that I'm stupid if I am wrong somewhere, but I think > >DESTDIR support, being introduced into ports collection in a way it's > >currently introduced, will bring much pain. > It will, but I tried to avoid the most of the necessary pain. Changing > all of *_DEPENDS would be good? I don't think so... As for this change, > it is actually wrong. I CC'd the maintainer. > In the HEADS-UP message I sent, I wrote that one can feel free to > contact me to review and test patches. Some people already did so. As my > time lets me doing so, I test every patches sent to me. > >What I propose is: > >- Change variable naming scheme. > >All *BASE and *DIR vars should be reverted to their original meanings > >(i.e. local paths). Instead, INSTALL_ vars should be introduced: > >INSTALL_LOCALBASE=${DESTDIR}/${LOCALBASE} > >INSTALL_X11BASE=${DESTDIR}/${X11BASE} > >INSTALL_PREFIX=${DESTDIR}/${PREFIX} > >INSTALL_DATADIR=${DESTDIR}/${DATADIR} > I don't think it will happen. It just makes the whole thing much more > complicated. Why? I don't think introducing INSTALL_* vars is more complicated than introducing *_REL, with the difference that it'll be more clear what to use in ports and it'll be easier to convert ports. Yes, there'll be some additional changes to Mk/* (hm, prepending DESTDIR where necessary doesn't seem compicating to me at all) but am I now right that Mk/* exists to support ports, not otherwise? Also, I may be wrong here, but I think that smaller set of wars is used in installation that in build process. At the end, DESTDIR is about installation - it seems pretty unlogical to me that everything except installation in ports have to be changed. Even not all vars were introduced (I think using :S to get local DATADIR is not the good way). > >etc. These should be used in do-install target. > > > >* This is far more clean and understandable, > >* This allows us to make all ports (around 5k) that define do-install > >target > > DESTDIR-compatible (there still may be issues, but nevertheless). > > > >- Introduce variable DESTDIR_COMPATIBLE to explititely mark > > DESTDIR-compatible ports. > This is going to happen but in the opposite manner. We are planning to > run an -exp run in the pointyhat cluster with DESTDIR set, and fix at > least some of the most common ports, and mark the other ones NO_DESTDIR > or something like that. Uh, that's good then. What's -exp by the way? > >* I don't think DESTDIR compatibility can be tested automatically, so > > this would make freebsd user's life easier (user will be sure that after > > he > > installs ports into [jail|other freebsd installation mounted via > > nfs|locally] being set corresponging DESTDIR, nothing will break). > > Without such variable, he'll never be sure. > >* Port maintainers will know what ports still are to be converted. > > Nothing will be forgotten. > P.S.: Please don't make other people panic with such subject. Other > people also reviewed my code. We are just people, so we can make > mistakes as well, but you can be sure that such a big change like > DESTDIR got enough reviewal and test before committed into Mk. Portmgr > is for ensuring people that only rational and working code gets > committed into bsd.port.mk. > John, the author of an earlier DESTDIR implementation also reviewed my > changes and helped to fix some minor issues. Yep, sorry for emotions. I have nothing against your or your code or people who reviewed it. It works pretty well, DESTDIR support is of course thing to have. But, we still have 15k ports to support it as well. So, what I propose is to make necessary changes in ports well-determined (i.e. only change known set of vars - X11BASE, PREFIX, DATADIR etc to their INSTALL_* equivalents in install targets - and nothing else, and if port doesn't support DESTDIR, cause is 100% in install process - and nowhere else), so no other parts of any port are to be touched (changing * to *_REL in post-patch and other targets will lead to more potential errors). Also what I propose satisfy UNIX's rules of clarity and least surprise more. -- Best regards, Dmitry mailto:amdmi3@mail.ru