Re: Request to review: print/texlive-install
On 2012.05.28. 18:16, Stephen Montgomery-Smith wrote: On 5/28/12 10:11 AM, Stephen Montgomery-Smith wrote: How about if I add lines like this: .if !defined(IGNORE_SECURITY_RISK) IGNORE= has a security risk because it downloads a file \ without a checksum. Define IGNORE_SECURITY_RISK to build this port .endif Would it be considered OK to commit it then? could you host it somewhere that won't go away at missouri.edu? I could host it somewhere at missouri.edu that will stay as long as I am alive or keep my job. Better to host it on the FreeBSD mirrors. You only have to create a public_distfiles in your home directory after logging in to freefall and drop the file there. This is the usual way of doing it. Gabor ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [PATCH] upgrade shells/bash to version 4.0
David O'Brien escribió: I need to get shells/bash repocopied before I can commit this. But I wanted to let folks play with the upgrade if they wanted to. I suggest using single distfile for both ones. I see that using this PATCHLEVEL method seems easier to handle when updating, but the other way isn't more diffcult either, you can just modify PORTVERSION and run make makesum. The point is that those patches are small but they can seriously prolong the fetching phase of the build due the enormous number of FTP transactions. Regards, -- Gabor Kovesdan FreeBSD Volunteer EMAIL: ga...@freebsd.org .:|:. ga...@kovesdan.org WEB: http://people.FreeBSD.org/~gabor .:|:. http://kovesdan.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: archivers/rar: lib32 is not actually needed on amd64
Andriy Gapon escribió: on 20/10/2008 17:14 Andriy Gapon said the following: I try to install archivers/rar on amd64 system without 32-bit userland (NO_LIB32) but with 32-bit support in kernel (COMPAT_IA32) and I get the following error: ** Port marked as IGNORE: archivers/rar: requires 32-bit libraries installed under /usr/lib32 On the other hand, if I comment out the following line in port's Makefile I get successful installation and properly working rar: IA32_BINARY_PORT= YES And also: $ file /usr/local/bin/rar /usr/local/bin/rar: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), statically linked, stripped So, being a static executable rar can not require any libraries. It does require 32-bit support in kernel, of course. So, I think that IA32_BINARY_PORT should be changed to some other check. E.g. something like IA32_STATIC_BINARY_PORT that would check only for HAVE_COMPAT_IA32_KERN and not for HAVE_COMPAT_IA32_LIBS (speaking in terms of bsd.port.mk). I am CC-ing freebsd-ports because there can be other similar ports that could benefit from the suggested relaxed check. Anyone? I'm sorry, I forgot about your first mail because I was very busy. I'll take a look soon. Regards, -- Gabor Kovesdan EMAIL: [EMAIL PROTECTED] WWW: http://www.kovesdan.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: jakarta-tomcat v.s. tomcat
Yoshihiro Ota escribió: Hello, forks. There are 2 directories for apache-tomcat like the following. % ls -d */*tomcat* java/eclipse-sysdeo-tomcat www/tomcat41 www/jakarta-tomcat4 www/tomcat55 www/jakarta-tomcat5 www/tomcat6 www/tomcat-native When I diffed ver. 5 dirs, they looked similar except versions. Does anyone know the differences between jakarta-tomcat and tomcat under the ports? Afaik, it used to be known as Jakarta-Tomcat, but its new name is Tomcat. If you observe it well www/tomcat41 and www/tomcat55 are much newer version than www/jakarta-tomcat4 and www/jakarta-tomcat5 and there isn't even www/jakarta-tomcat6. I suggest you should just use www/tomcat6. I'm also planning to use it and I succeeded to install it without problems and I can reach it through the port 8180. -- Gabor Kovesdan EMAIL: [EMAIL PROTECTED] WWW: http://www.kovesdan.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Wacom driver
Dominic Fandrey escribió: I have created a port of Bartosz Fabianowski's Wacom driver. Since nobody has stepped forward to commit it, I thought I'd inform this list, so that people can test it. http://www.freebsd.org/cgi/query-pr.cgi?pr=128547 I suggest that you should consult with [EMAIL PROTECTED] He was going to port this driver himself but he hasn't got time so far. I've CC'd him because I don't think he is on the ports@ list because he is a doc committer. Cheers, -- Gabor Kovesdan EMAIL: [EMAIL PROTECTED] WWW: http://www.kovesdan.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Is postgresql83-server broken?
Palle Girgensohn escribió: I submitted a patch yesterday the I think fixes this problem. Please try upgrading, and if it still doesn't work, email me again. I had another problem with 8.3. After installing, initdb couldn't create a new database. I needed to get a PostgreSQL server installed quickly, thus I didn't save the output... Has anyone else experienced the same? -- Gabor Kovesdan EMAIL: [EMAIL PROTECTED] WWW: http://www.kovesdan.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bsd-grep-20080725_1 -v flag busted...
Chuck Swiger escribió: I'd just updated the BSD grep port to bsd-grep-20080725_1, but regrettably have noticed that many things using grep stopped working. For example, running GNU-style ./configure hangs here: configure: creating ./config.status load: 1.15 cmd: sh 72964 [runnable] 7.60u 95.78s 14% 2260k A trivial test case: % echo 'fee\nfi\nfoe\nfum' | ./grep -v fi % echo 'fee\nfi\nfoe\nfum' | /usr/bin/grep -v fi fee foe fum % ./grep --version grep (BSD grep) 2.5.1-FreeBSD Hello Chuck, thanks for your notes. It seems very strange to me, because GNU grep produces the same output for me. Apart from this, the -v flag was really broken, but I applied some fixes before updating the port and in the version, which I committer, I thought that the -v flag was compatible. Here is what I get at the moment: echo 'fee\nfi\nfoe\nfum' | ./grep -v fi echo 'fee\nfi\nfoe\nfum' | /usr/bin/grep -v fi /usr/bin/grep -V grep (GNU grep) 2.5.1-FreeBSD Copyright 1988, 1992-1999, 2000, 2001 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It's still the same, thus I don't understand how you could produce that output with GNU grep. Best, -- Gabor Kovesdan EMAIL: [EMAIL PROTECTED] WWW: http://www.kovesdan.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to [EMAIL PROTECTED]
[Call for testers] BSD ar [Was: Fwd: cvs commit: ports/archivers Makefile ports/archivers/bsdar Makefile distinfo pkg-descr]
As I discussed with Kai, I just added a port to make the testing of this cool new stuff easier. Enjoy! Regards, -- Gabor Kovesdan EMAIL: [EMAIL PROTECTED] WWW: http://www.kovesdan.org ---BeginMessage--- gabor 2008-01-18 23:11:34 UTC FreeBSD ports repository Modified files: archiversMakefile Added files: archivers/bsdar Makefile distinfo pkg-descr Log: A BSD-licensed replacement of the ar utility. Written by: Kai Wang [EMAIL PROTECTED] Sponsored by: Google Summer of Code 2007 Revision ChangesPath 1.186 +1 -0 ports/archivers/Makefile 1.1 +33 -0 ports/archivers/bsdar/Makefile (new) 1.1 +3 -0 ports/archivers/bsdar/distinfo (new) 1.1 +2 -0 ports/archivers/bsdar/pkg-descr (new) ---End Message--- ___ 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:
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]
HEADS-UP: [Fwd: Re: Future plans for DESTDIR]
Hi folks, sometimes good ideas come later, so please wait a bit with making your ports DESTDIR-aware. Kris had a very interesting suggestion. I wonder how we haven't thought of this so far. This needs a bit more of discussion, though, but if we can work this out a bit better, things will become very easy. Comments are welcome. -- Cheers, Gabor ---BeginMessage--- On Wed, Aug 16, 2006 at 06:30:35PM +0200, Erwin Lansing wrote: On Tue, Aug 15, 2006 at 11:03:56PM +0200, G?bor K?vesd?n wrote: Hi Erwin, Hi, I tried to talk to you on irc, but you seemed to be quite busy today. Unfortunately, some people are unsatisfied and disappointed with my DESTDIR implementation. I don't know what to do now, since I just did what we discussed to avoid big changes all over the ports tree. A guy complained that LOCALBASE, LINUXBASE and X11BASE should be reverted, but we discussed it is wrong, because we had to change *_DEPENDS all over Right. The idea here was to get DESTDIR added without having to change a huge number of ports. Somehow the PREFIX problem got overlooked. the ports tree. That definitely should not happen. Andrew (infofarmer@) suggested to change PREFIX to fully qualified so that we don't need to do s/PREFIX/TARGETDIR/ and introduce PREFIX_REL for sed substitutions. With this we could also keep TARGETDIR for compatibility, but I should now how portmgr feels about this before I start to work on this. Andrew's way seems to be reasonable for me. It changes the interpretation of PREFIX, but this change won't violate POLA, I can workaround that with a hackery, and according to Andrew, we would get many of the ports DESTDIR aware without much pain. This would fix the install time location, without having to change all port install targets. It does significantly change the behaviour of PREFIX though, which is assumed to be under DESTDIR (see /usr/share/mk/), so it's hard to see all the consequences beforehand and it would be good to see an implementation first. I think that would also produce a lot of hidden landmines, because PREFIX is hard-coded into many binaries for referring to the location of installed files at runtime. So is LOCALBASE et al, which is why none of them can have DESTDIR prepended automatically. The only simple solution I can think of (which doesn't involve modifying thousands of ports one way or another) is the mount_nullfs+chroot method I mentioned previously. Also, keeping TARGETDIR should only be a temporary measure until those ports that have been changed are changed back. You probably should tell people on ports@ that you're working on this issue and that we do not want to see any more TARGETDIR changes committed until we find the best way forward. Kris pgpXPORL7fE3f.pgp Description: PGP signature ---End Message--- ___ 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:
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?]
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]
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: support for DESTDIR: security/openssh-portable
Brooks Davis wrote:
On Thu, Aug 10, 2006 at 03:25:38PM +0200, G?bor K?vesd?n wrote:
Brooks Davis wrote:
On Wed, Aug 09, 2006 at 05:59:18PM -0600, John E Hein wrote:
John E Hein wrote at 17:43 -0600 on Aug 9, 2006:
Well, the part that makes it annoying to duplicate in all ports is not
the two separate words (CHROOT DESTDIR), but that you have to test
defined(DESTDIR) !empty(DESTDIR) before you can figure out whether
to use ${CHROOT} ${DESTDIR} or not.
So having that test to assign CHROOTDESTDIR or leave it empty in
bsd.port.mk allows the port writer to just always invoke it without
having to worry about testing for DESTDIR.
You could pass this var to pkg-install scripts, too (put it in the
standard *SUB* lists).
That way you don't have to do the dance that was added to
security/clamav/files/pkg-install.in:
if [ -n %%DESTDIR%% ]; then
PW=/usr/sbin/chroot %%DESTDIR%% pw
CHOWN=/usr/sbin/chroot %%DESTDIR%% chown
MKDIR=/usr/sbin/chroot %%DESTDIR%% mkdir -p
else
PW=pw
CHOWN=chown
MKDIR=mkdir -p
fi
but rather just:
PW=%%CHROOTDESTDIR%% pw
CHOWN=%%CHROOTDESTDIR%% chown
MKDIR=%%CHROOTDESTDIR%% mkdir -p
This seems bogus. I can't think of any good reason why packages should
differ based on the valid of DESTDIR. Instead the pkg-install script
should be run inside the chroot.
-- Brooks
We wanted to go that way with garga when working on security/clamav, but
we realized that we can't just do chroot /foo pkg-install, since the
script is not located in the chroot itself. Do you have an another idea,
how to chroot those scripts?
My inclination would be something like:
PKG_INSTALL_TEMP=`mktemp ${DESTDIR}/tmp/pkg_install` \
(${CAT} ${PKG_INSTALL} ${PKG_INSTALL_TEMP}; \
${SH} ${PKG_INSTALL_TEMP}; \
${RM} ${PKG_INSTALL_TEMP})
I think we should ideally introduce a feature to allow ports to
automatically run pkg-install and stuff the code in bsd.port.mk so ports
don't have to know about DESTDIR in this case. Actually, ports where
pkg-install and the pre/post-install targets duplicate code (often
slightly differently) drive me nuts so I'd prefer a NO_AUTOPKGINSTALL,
but that would take some real work so a positive flag is probably better
initially.
-- Brooks
This is a good idea, but there's a big mess in this area as you already
said, so I think it would be a long term goal. I find John's solution
pretty good for now. An another item for automatization would be to
install PORTDOCS into DOCSDIR in post-install phase. and introduce
NO_PORTDOCSINSTALL or something like that to turn this off. But both of
them needs a lot of modification in affected ports as well.
--
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: support for DESTDIR: security/openssh-portable
Brooks Davis wrote:
On Wed, Aug 09, 2006 at 05:59:18PM -0600, John E Hein wrote:
John E Hein wrote at 17:43 -0600 on Aug 9, 2006:
Well, the part that makes it annoying to duplicate in all ports is not
the two separate words (CHROOT DESTDIR), but that you have to test
defined(DESTDIR) !empty(DESTDIR) before you can figure out whether
to use ${CHROOT} ${DESTDIR} or not.
So having that test to assign CHROOTDESTDIR or leave it empty in
bsd.port.mk allows the port writer to just always invoke it without
having to worry about testing for DESTDIR.
You could pass this var to pkg-install scripts, too (put it in the
standard *SUB* lists).
That way you don't have to do the dance that was added to
security/clamav/files/pkg-install.in:
if [ -n %%DESTDIR%% ]; then
PW=/usr/sbin/chroot %%DESTDIR%% pw
CHOWN=/usr/sbin/chroot %%DESTDIR%% chown
MKDIR=/usr/sbin/chroot %%DESTDIR%% mkdir -p
else
PW=pw
CHOWN=chown
MKDIR=mkdir -p
fi
but rather just:
PW=%%CHROOTDESTDIR%% pw
CHOWN=%%CHROOTDESTDIR%% chown
MKDIR=%%CHROOTDESTDIR%% mkdir -p
This seems bogus. I can't think of any good reason why packages should
differ based on the valid of DESTDIR. Instead the pkg-install script
should be run inside the chroot.
-- Brooks
We wanted to go that way with garga when working on security/clamav, but
we realized that we can't just do chroot /foo pkg-install, since the
script is not located in the chroot itself. Do you have an another idea,
how to chroot those scripts?
--
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: HEADS-UP: DESTDIR support committed to Mk/
Edwin Groothuis wrote:
On Fri, Aug 04, 2006 at 06:08:09PM +0200, G?bor K?vesd?n wrote:
I am pleased to announce, that portmgr committed my patch for ports
infrastructure DESTDIR support today. Note that this support is only for
the infrastructure, ports may or may not respect the DESTDIR macro, so
Having read the wiki, please let me ask a couple of questions to
make sure there is consensus on what needs to be done to make all
ports DESTDIR happy.
- All ports Makefiles should be checked for installs into PREFIX,
and replaced by TARGETDIR (or DESTDIR/PREFIX)
Yes, TARGETDIR resolves to DESTDIR/PREFIX, which should be the final
destination. In many ports we have a do-install or post-install target
with something like:
@${INSTALL_PROGRAM} ${WRKSRC}/foo ${PREFIX}/bin
This is definitely not good, since it will install to ${PREFIX} even if
you set DESTDIR, so this needs a s/${PREFIX}/${TARGETDIR}/.
The other type of stuff when ports specify some paths that are used in
run-time, e.g. where a specific port checks for its configuration stuff.
Of course, there the relative path (relative to DESTDIR, but absolute
anyway) should be kept, since the given program is supposed to run in
the DESTDIR environment chrooted or jailed.
- All Makefiles in the workdir should install the DESTDIR/PREFIX,
so their configure options should be... --prefix? Not really,
because the datafiles of the program itself are to be found at
PREFIX, not DESTDIR/PREFIX. Any idea how to resolve this?
Edwin
If you mean the config files on datafiles, I already answered, if no, I
don't really see what you mean. For configure options, GNU stuff is
aware of the DESTDIR macro, so those ports should be easy to modify to
respect DESTDIR. E.g. I experimented with devel/gmake, and needed only a
little effort. No need to use --prefix=${DESTDIR}${PREFIX} at all, just
${PREFIX} and ${DESTDIR} is passed via CONFIGURE_ENV.
--
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: HEADS-UP: DESTDIR support committed to Mk/
Andrey Chernov wrote:
On Sat, Aug 05, 2006 at 10:49:11AM +0200, G?bor K?vesd?n wrote:
Edwin Groothuis wrote:
On Fri, Aug 04, 2006 at 06:08:09PM +0200, G?bor K?vesd?n wrote:
I am pleased to announce, that portmgr committed my patch for ports
infrastructure DESTDIR support today. Note that this support is only for
the infrastructure, ports may or may not respect the DESTDIR macro, so
Having read the wiki, please let me ask a couple of questions to
make sure there is consensus on what needs to be done to make all
ports DESTDIR happy.
- All ports Makefiles should be checked for installs into PREFIX,
and replaced by TARGETDIR (or DESTDIR/PREFIX)
Yes, TARGETDIR resolves to DESTDIR/PREFIX, which should be the final
destination. In many ports we have a do-install or post-install target
with something like:
@${INSTALL_PROGRAM} ${WRKSRC}/foo ${PREFIX}/bin
This is definitely not good, since it will install to ${PREFIX} even if
you set DESTDIR, so this needs a s/${PREFIX}/${TARGETDIR}/.
It will be much better to not change that in almost in every port, but
change meaning of PREFIX instead:
PREFIX == DESTDIR/DESTPREFIX
That would be quite a wrong interpretation of PREFIX and would violate
POLA, since it can't be overridden anymore in the old context. Another
reason not to do so is, that we need the current PREFIX for the relative
paths I talked about for hardcoding the run-time paths of config files,
etc. We would need to change those to DESTPREFIX then.
--
Cheers,
Gabor
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADS-UP: DESTDIR support committed to Mk/
Hi, I am pleased to announce, that portmgr committed my patch for ports infrastructure DESTDIR support today. Note that this support is only for the infrastructure, ports may or may not respect the DESTDIR macro, so you should use this with care. Also note, that we only tested this patchset without the DESTDIR macro set, but will do an another one with DESTDIR set to something and check how many ports respect DESTDIR and how many left to fix, but port maintainers can start checking their ports and fixing them if necessary. Unfortunately, testing ports for DESTDIR is pretty difficult, since we don't have support for this in tinderbox. I used a chroot jail installed into an another chroot jail to ensure I won't make my filesystem dirty. I chrooted into the first jail and run make install for the given port with DESTDIR set to the another chroot jail, checked if everything went fine and did make deinstall and checked if everything is still good. I know it's a bit complicated, but we don't have better yet. I've also written a Wiki page for DESTDIR with some guidelines what to care about when writing DESTDIR-respective ports. You can find it here: http://wikitest.freebsd.org/DESTDIR I also suggest to read the CHANGES entry, if you haven't done this yet: http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/ports/CHANGES?rev=1.57content-type=text/plain Documentation update for porters-handbook will also come soon. If you have questions, please feel free to contact me. -- 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: graphics/png - CC
[LoN]Kamikaze wrote:
Andrey Chernov wrote:
On Sat, Jul 29, 2006 at 02:59:19PM -0500, Jeremy Messenger wrote:
On Sat, 29 Jul 2006 13:27:08 -0500, [LoN]Kamikaze [EMAIL PROTECTED]
wrote:
Andrey Chernov wrote:
On Sat, Jul 29, 2006 at 01:16:47PM -0500, Jeremy Messenger wrote:
On Fri, 28 Jul 2006 18:35:14 -0500, Andrey Chernov [EMAIL PROTECTED]
wrote:
On Fri, Jul 28, 2006 at 11:40:10AM +0200, [LoN]Kamikaze wrote:
The port graphics/png does not honour the CC Variable.
I can't reproduce that, it honors CC for me.
I can, CC=gcc will not change the CC when it compiles.
It is hard to imagine how it is ever possible. There is standard BSD
makefile.freebsd which not owervrites CC as you can see in the file.
No idea, I don't know png's build system so that cc must be come from
somewhere.
Is it possible that make.conf is read again?
I think, add CC=${CC} in graphics/png/Makefile's MAKE_ENV at 31 line
should do.
It will be hack for reason unknown, I prefer to avoid that.
I normally set CC to anything and it honors.
I never heard from somebody other than you about that problem.
You should inspect your build path step by step to find real reason of
that bag, only after that we can find the real fix.
The problem is there, without doubt. Normally bsd.port.mk only forwards CC to
the configure script (look for the do-configure target). Since the configure
target is omitted the port will not receive CC. This is why it has to be
included into the make environment. I.e. with
MAKE_ENV+= CC=${CC}
This is not a hack, but a necessity, due to the lack of a configure step.
Then tell me why it works for me and for Andrey.
--
Cheers,
Gabor
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to [EMAIL PROTECTED]
