Date: Tue, 15 Aug 2006 12:37:50 -0600 From: John E Hein <jhein@timing.com> To: =?UTF-8?B?R8OhYm9yIEvDtnZlc2TDoW4=?= <gabor@FreeBSD.org> 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?] Message-ID: <17634.5246.887894.836856@gromit.timing.com> In-Reply-To: <44E194BA.2020507@FreeBSD.org> References: <20060814234414.GA57035@hades.panopticon> <44E194BA.2020507@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17634.5246.887894.836856>