Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Kris Kennaway wrote:
On Tue, Aug 15, 2006 at 12:37:50PM -0600, John E Hein wrote:
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.
My preferred solution involves a couple of shell commands, along the
lines of the following:
mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
mount_devfs foo ${DESTDIR}/dev
chroot ${DESTDIR} cd ${.CURDIR} make install
A suitable version of the above should allow all ports to be installed
into a jail-ready filesystem hierarchy, while requiring 0 port
changes.
Kris
Ok, I think it's time to follow this way, but have to make some parts
clearer. For your last line, it should be
chroot ${DESTDIR} cd ${.CURDIR} make ${.TARGETDIR}
since we want to run all targets chrooted. We could put this part into
an .if defined(DESTDIR) block before the targets, but I don't know how
to prevent running the further code, since we don't want to reach
do-install in the host environment, but only in the chroot. I think of
exit 0, if that's correct, or what else is better.
So, what I mean:
.if defined(DESTDIR)
.BEGIN # We need this if not in a target
${MOUNT_NULLFS} ${PORTSDIR} ${DESTDIR}${PORTSDIR}
${MOUNT_NULLFS} ${WRKDIR} ${DESTDIR}${WRKDIR}
${MOUNT_DEVFS} foo ${DESTDIR}/dev
${CHROOT} ${DESTDIR} cd ${.CURDIR} ${MAKE} ${.TARGETDIR}
exit 0
.endif
The new variables I used should be overrideable, if someone would like
to use some kind of script or so.
The another issue I find is how we can pass variables to the chrooted
make. E.g. if we want to set WITH_FOO in command line or in make.conf.
And note, that we can't just pass everything, since DESTDIR should be
unset in the chroot, otherwise we would run into infinite loop and it
would fail due to the non-existent directories.
--
Cheers,
Gabor
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
On Tue, Aug 15, 2006 at 12:37:50PM -0600, John E Hein wrote:
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.
My preferred solution involves a couple of shell commands, along the
lines of the following:
mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
mount_devfs foo ${DESTDIR}/dev
chroot ${DESTDIR} cd ${.CURDIR} make install
A suitable version of the above should allow all ports to be installed
into a jail-ready filesystem hierarchy, while requiring 0 port
changes.
Kris
pgpRmQwsNEDxa.pgp
Description: PGP signature
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Kris Kennaway wrote:
On Wed, Aug 16, 2006 at 07:55:20PM +0200, G?bor K?vesd?n wrote:
Kris Kennaway wrote:
On Tue, Aug 15, 2006 at 12:37:50PM -0600, John E Hein wrote:
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.
My preferred solution involves a couple of shell commands, along the
lines of the following:
mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
mount_devfs foo ${DESTDIR}/dev
chroot ${DESTDIR} cd ${.CURDIR} make install
A suitable version of the above should allow all ports to be installed
into a jail-ready filesystem hierarchy, while requiring 0 port
changes.
Kris
This makes sense, but I did not succeed to use mount_nullfs on an
5.3-RELEASE/amd64 machine, while the same worked well on my 6.1/i386
computer, so I'm not sure mount_nullfs is reliable enough on older systems.
Who cares about old systems that are already unsupported and will only
become even more unsupported over time? Nullfs works in 6.x and will
continue to work in the future (since I use it extensively and yell at
whoever breaks it ;-)
Also, other targets should be supported as well, and the nullmounted
directory should be umounted after he run. Anyway, I find this solution
very good, if we can work this out a bit better, my progress so far
would become pointless...
It's a shame to throw away your work, but IMO it would also be a
bigger shame not to proceed if a simpler solution can be made to work.
Kris
Agreed. I just feel a bit guilty, since I made things complicated and
obscure, while I just want to provide a good solution, but haven't
thought of mount_nullfs.
--
Cheers,
Gabor
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Kris Kennaway wrote at 13:36 -0400 on Aug 16, 2006:
mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
mount_devfs foo ${DESTDIR}/dev
chroot ${DESTDIR} cd ${.CURDIR} make install
A suitable version of the above should allow all ports to be installed
into a jail-ready filesystem hierarchy, while requiring 0 port
changes.
I do that, too - we _have_ to since DESTDIR never worked right.
That's more heavyweight than a DESTDIR chroot (which doesn't need to
have much more than pkg* tools libc a few others), but that's a
very minor advantage over a full chroot (and probably not worth trying
to special case). My original DESTDIR fix didn't involve a chroot
at all, but runs into problems with pkg management.
Note that if we go that route (just run completely within a chroot),
we might as well just rip DESTDIR support out of Mk/*.mk altogether.
That would be better than the fake support for DESTDIR.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
On Wed, Aug 16, 2006 at 08:14:08PM +0200, G?bor K?vesd?n wrote:
Kris Kennaway wrote:
On Wed, Aug 16, 2006 at 07:55:20PM +0200, G?bor K?vesd?n wrote:
Kris Kennaway wrote:
On Tue, Aug 15, 2006 at 12:37:50PM -0600, John E Hein wrote:
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.
My preferred solution involves a couple of shell commands, along the
lines of the following:
mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
mount_devfs foo ${DESTDIR}/dev
chroot ${DESTDIR} cd ${.CURDIR} make install
A suitable version of the above should allow all ports to be installed
into a jail-ready filesystem hierarchy, while requiring 0 port
changes.
Kris
This makes sense, but I did not succeed to use mount_nullfs on an
5.3-RELEASE/amd64 machine, while the same worked well on my 6.1/i386
computer, so I'm not sure mount_nullfs is reliable enough on older
systems.
Who cares about old systems that are already unsupported and will only
become even more unsupported over time? Nullfs works in 6.x and will
continue to work in the future (since I use it extensively and yell at
whoever breaks it ;-)
Also, other targets should be supported as well, and the nullmounted
directory should be umounted after he run. Anyway, I find this solution
very good, if we can work this out a bit better, my progress so far
would become pointless...
It's a shame to throw away your work, but IMO it would also be a
bigger shame not to proceed if a simpler solution can be made to work.
Kris
Agreed. I just feel a bit guilty, since I made things complicated and
obscure, while I just want to provide a good solution, but haven't
thought of mount_nullfs.
The one advantage I can see for a more complex DESTDIR solution is
dealing with cross builds. I suspect that it would be easier to handle
them with DESTDIR, but that's only intuition. (Obviously, not all ports
can be easily cross built, but as embedded becomes more important to the
project we need to start thinking about it for the ones that can be).
-- Brooks
pgplDdMWM2NGW.pgp
Description: PGP signature
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Brooks Davis wrote:
On Wed, Aug 16, 2006 at 08:14:08PM +0200, G?bor K?vesd?n wrote:
Kris Kennaway wrote:
On Wed, Aug 16, 2006 at 07:55:20PM +0200, G?bor K?vesd?n wrote:
Kris Kennaway wrote:
On Tue, Aug 15, 2006 at 12:37:50PM -0600, John E Hein wrote:
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.
My preferred solution involves a couple of shell commands, along the
lines of the following:
mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
mount_devfs foo ${DESTDIR}/dev
chroot ${DESTDIR} cd ${.CURDIR} make install
A suitable version of the above should allow all ports to be installed
into a jail-ready filesystem hierarchy, while requiring 0 port
changes.
Kris
This makes sense, but I did not succeed to use mount_nullfs on an
5.3-RELEASE/amd64 machine, while the same worked well on my 6.1/i386
computer, so I'm not sure mount_nullfs is reliable enough on older
systems.
Who cares about old systems that are already unsupported and will only
become even more unsupported over time? Nullfs works in 6.x and will
continue to work in the future (since I use it extensively and yell at
whoever breaks it ;-)
Also, other targets should be supported as well, and the nullmounted
directory should be umounted after he run. Anyway, I find this solution
very good, if we can work this out a bit better, my progress so far
would become pointless...
It's a shame to throw away your work, but IMO it would also be a
bigger shame not to proceed if a simpler solution can be made to work.
Kris
Agreed. I just feel a bit guilty, since I made things complicated and
obscure, while I just want to provide a good solution, but haven't
thought of mount_nullfs.
The one advantage I can see for a more complex DESTDIR solution is
dealing with cross builds. I suspect that it would be easier to handle
them with DESTDIR, but that's only intuition. (Obviously, not all ports
can be easily cross built, but as embedded becomes more important to the
project we need to start thinking about it for the ones that can be).
-- Brooks
Oh, yes. I have also thought of cross-building with DESTDIR. And there
is a PR assigned to portmgr that requests a new feature, a plist make
target. Plists could also be generated with installing into a temporary
DESTDIR environment.
--
Cheers,
Gabor
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
On Wed, Aug 16, 2006 at 01:35:22PM -0500, Brooks Davis wrote:
On Wed, Aug 16, 2006 at 08:14:08PM +0200, G?bor K?vesd?n wrote:
Kris Kennaway wrote:
On Wed, Aug 16, 2006 at 07:55:20PM +0200, G?bor K?vesd?n wrote:
Kris Kennaway wrote:
On Tue, Aug 15, 2006 at 12:37:50PM -0600, John E Hein wrote:
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.
My preferred solution involves a couple of shell commands, along the
lines of the following:
mount_nullfs ${PORTSDIR} ${DESTDIR}${PORTSDIR}
mount_nullfs ${WRKDIR} ${DESTDIR}${WRKDIR}
mount_devfs foo ${DESTDIR}/dev
chroot ${DESTDIR} cd ${.CURDIR} make install
A suitable version of the above should allow all ports to be installed
into a jail-ready filesystem hierarchy, while requiring 0 port
changes.
Kris
This makes sense, but I did not succeed to use mount_nullfs on an
5.3-RELEASE/amd64 machine, while the same worked well on my 6.1/i386
computer, so I'm not sure mount_nullfs is reliable enough on older
systems.
Who cares about old systems that are already unsupported and will only
become even more unsupported over time? Nullfs works in 6.x and will
continue to work in the future (since I use it extensively and yell at
whoever breaks it ;-)
Also, other targets should be supported as well, and the nullmounted
directory should be umounted after he run. Anyway, I find this solution
very good, if we can work this out a bit better, my progress so far
would become pointless...
It's a shame to throw away your work, but IMO it would also be a
bigger shame not to proceed if a simpler solution can be made to work.
Kris
Agreed. I just feel a bit guilty, since I made things complicated and
obscure, while I just want to provide a good solution, but haven't
thought of mount_nullfs.
The one advantage I can see for a more complex DESTDIR solution is
dealing with cross builds. I suspect that it would be easier to handle
them with DESTDIR, but that's only intuition. (Obviously, not all ports
can be easily cross built, but as embedded becomes more important to the
project we need to start thinking about it for the ones that can be).
That's something that can be looked at if and when someone starts
seriously working on cross-build support - I suspect it will never be
enough of a demand to warrant the cost of the alternative solutions.
Kris
pgp3oH9TSvVJJ.pgp
Description: PGP signature
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Gábor Kövesdán wrote: if we can work this out a bit better, my progress so far would become pointless... Not at all! If I had a dollar for every Good Idea(TM) that I had which ended up leading me down a completely different road, I'd be retired now. These are not easy problems, and the fact that you put a lot of thought and effort into getting us where we are now should be acknowledged and appreciated, not the least of which by you yourself. :) Doug -- This .signature sanitized for your protection ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
* Doug Barton ([EMAIL PROTECTED]) wrote: if we can work this out a bit better, my progress so far would become pointless... Not at all! If I had a dollar for every Good Idea(TM) that I had which ended up leading me down a completely different road, I'd be retired now. These are not easy problems, and the fact that you put a lot of thought and effort into getting us where we are now should be acknowledged and appreciated, not the least of which by you yourself. :) Yep. I'm very grateful for change is OSVERSION detection, for example. Now I don't need to specify it in make.conf when I chroot into different environment. Nothing is forgotten, nobody is forgotten :) -- Best regards, Dmitry mailto:[EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
On Thu, Aug 17, 2006 at 12:20:09AM +0400, Dmitry Marakasov wrote: * Both current and nullfs-drived DESTDIR implementations require all depends in the DESTDIR. But actually BUILD_DEPENDS from host can be used. This should already be the case with the current implementation and also will need to be with any new one. The chroot should be used at install time only, thus using BUILD_DEPENDS from the host environment. -erwin -- Erwin Lansing http://droso.org Security is like an onion. (o_ _o) It's made up of several layers \\\_\ /_///[EMAIL PROTECTED] And it makes you cry.) ([EMAIL PROTECTED] pgpRwtrB8W7Sz.pgp Description: PGP signature
Re: ATTENTION: is the way DESTDIR was introduced completely wrong?
Dmitry Marakasov wrote:
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}
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).
I agree with every your word.
- Introduce variable DESTDIR_COMPATIBLE to explititely mark
DESTDIR-compatible ports.
* 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.
This is exactly I proposed. But I've not been heard.
--
Dixi.
Sem.
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Dmitry Marakasov wrote:
Hi!
I'm now exploring new DESTDIR-related stuff, and I find it far from
being useable. More of that, DESTDIR-related changes seem dangerous
to me.
As far as I understand, for port to support DESTDIR, it's files
should be installed into ${DESTDIR}/${PREFIX}/foo (aka ${TARGETDIR}/foo),
but all paths compiled into binaries (or config files) should remain
`local' (i.e. ${PREFIX}/foo). Thus, when DESTDIR used, port will
be installed into (for example) jail environment specified in
DESTDIR, and will correctly work in that environment after chroot'ing
into in. Am I right?
Yes.
Now, I think the way DESTDIR-related changes were done to bsd.port.mk is
absolutely wrong. For example, X11BASE, LOCALBASE, DATADIR now contain
DESTDIR. But, these variables are frequently used when changing paths
hardcoded in port's sources (see many of my ports, for example
games/fishsupper:
@${REINPLACE_CMD} -e 's|data/|${DATADIR}/|' ${WRKSRC}/src/getreadydisplay.cc
After change, all these ports will not support DESTDIR automatically.
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, 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...
Also I see that new TARGETDIR/DESTDIR/...DIR scheme brings confusion.
Latest DESTDIR-related port update that I see:
http://www.freshports.org/x11-wm/jwm/[EMAIL PROTECTED]
notice this:
(http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-wm/jwm/Makefile.diff?r1=1.11r2=1.12)
[EMAIL PROTECTED] -e 's|%%PREFIX%%|${PREFIX}|' ${WRKSRC}/example.jwmrc
[EMAIL PROTECTED] -e 's|%%PREFIX%%|${TARGETDIR}|' ${WRKSRC}/example.jwmrc
Now example.jwmrc will contain GLOBAL system path, not jail-local one,
which is of course wrong.
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.
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.
* 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.
Re: ATTENTION: is the way DESTDIR was introduced completely wrong?
Sergey Matveychuk wrote:
Dmitry Marakasov wrote:
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}
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).
I agree with every your word.
I was to implement it in this way, but as I said this would require us
to change all of the *_DEPENDS lines. Erwin told me that this can't be
happen, so I was pushed to go the another way. Erwin is in portmgr, and
portmgr's word make sense in these questions...
- Introduce variable DESTDIR_COMPATIBLE to explititely mark
DESTDIR-compatible ports.
* 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.
This is exactly I proposed. But I've not been heard.
You have been, but this will happen later, after an -exp run as Erwin
said. And in the opposite form. Ports that don't respect DESTDIR will be
marked.
--
Cheers,
Gabor
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATTENTION: is the way DESTDIR was introduced completely wrong?
* G??bor K??vesd??n ([EMAIL PROTECTED]) wrote: I agree with every your word. I was to implement it in this way, but as I said this would require us to change all of the *_DEPENDS lines. Erwin told me that this can't be happen, so I was pushed to go the another way. Erwin is in portmgr, and portmgr's word make sense in these questions... Why change _DEPENDS lines in ports while we can prepend DESTDIR where needed in bsd.port.mk? I can make the patches if needed. This is exactly I proposed. But I've not been heard. You have been, but this will happen later, after an -exp run as Erwin said. And in the opposite form. Ports that don't respect DESTDIR will be marked. Could you point me to any information regarding this -exp? Honestly I don't get how the software can be proven working without human inspection. Ok, there can be errors on stderr. But what about GUI software? There will be messageboxes, how to detect these? Or there will be no complaints at all, software just won't work properly (i.e. a game will run with no textures/no sound etc.). We may search for paths in all files installed by port (simple grep(1) on text files, strings(1)|grep on binaries) to detect wrong paths - that's far more reliable - is that what's done? -- Best regards, Dmitry mailto:[EMAIL PROTECTED] ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DESTDIR implementation [Was:: ATTENTION: is the way DESTDIR was introduced completely wrong?]
Gábor Kövesdán 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.mk is
absolutely wrong. For example, X11BASE, LOCALBASE, DATADIR now contain
DESTDIR. But, these variables are frequently used when changing paths
hardcoded in port's sources (see many of my ports, for example
games/fishsupper:
@${REINPLACE_CMD} -e 's|data/|${DATADIR}/|'
${WRKSRC}/src/getreadydisplay.cc
After change, all these ports will not support DESTDIR automatically.
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, 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 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ábor 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 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 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ábor is open to alternate ways to do things to
some
ATTENTION: is the way DESTDIR was introduced completely wrong?
Hi!
I'm now exploring new DESTDIR-related stuff, and I find it far from
being useable. More of that, DESTDIR-related changes seem dangerous
to me.
As far as I understand, for port to support DESTDIR, it's files
should be installed into ${DESTDIR}/${PREFIX}/foo (aka ${TARGETDIR}/foo),
but all paths compiled into binaries (or config files) should remain
`local' (i.e. ${PREFIX}/foo). Thus, when DESTDIR used, port will
be installed into (for example) jail environment specified in
DESTDIR, and will correctly work in that environment after chroot'ing
into in. Am I right?
Now, I think the way DESTDIR-related changes were done to bsd.port.mk is
absolutely wrong. For example, X11BASE, LOCALBASE, DATADIR now contain
DESTDIR. But, these variables are frequently used when changing paths
hardcoded in port's sources (see many of my ports, for example
games/fishsupper:
@${REINPLACE_CMD} -e 's|data/|${DATADIR}/|' ${WRKSRC}/src/getreadydisplay.cc
After change, all these ports will not support DESTDIR automatically.
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.
Also I see that new TARGETDIR/DESTDIR/...DIR scheme brings confusion.
Latest DESTDIR-related port update that I see:
http://www.freshports.org/x11-wm/jwm/[EMAIL PROTECTED]
notice this:
(http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-wm/jwm/Makefile.diff?r1=1.11r2=1.12)
[EMAIL PROTECTED] -e 's|%%PREFIX%%|${PREFIX}|' ${WRKSRC}/example.jwmrc
[EMAIL PROTECTED] -e 's|%%PREFIX%%|${TARGETDIR}|' ${WRKSRC}/example.jwmrc
Now example.jwmrc will contain GLOBAL system path, not jail-local one,
which is of course wrong.
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.
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}
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.
* 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.
--
Best regards,
Dmitry mailto:[EMAIL PROTECTED]
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ATTENTION: is the way DESTDIR was introduced completely wrong?
So now that Dmitry sounded a sober thought, I'll give a one of my own. I would rather see PREFIX respect DESTDIR and go through all the pains of respecting PREFIX. This way we reach a double cause: * ensure PREFIX is respected (this will reveal thousands of erring ports, but it will be worth it) * ensure DESTDIR is respected Also, we won't need to s/PREFIX/TARGETDIR/ anymore, a feat of quite questionable usefullness. For reasons that Dmitry highlighted, we'll need PREFIX_REL and some additional _REL's. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
