Re: CVS: cvs.openbsd.org: ports

Hello! [older mail] According to Warner Losh:
In message <199709160731.JAA11130@waldorf.appli.se> Niklas Hallqvist writes: : To people with commit access: committing to ports won't work, it's a : sup mirror where files will get overwritten. Instead discuss changes : on ports@ and when good, mail to imp@ with explanations for : consideration of including into FreeBSD.
This particular patch was committed to the FreeBSD tree last night.
I do think that there will come a time when OpenBSD needs to have its own ports tree. 95% of this tree could be a mirror of the FreeBSD, but there are some interesting issues that need to be resolved that haven't been (like the libcrypt issues).
How about suggesting a make variable HAS_LIBCRYPT to the FreeBSD people? We could set it in <bsd.own.mk> or something like this (to a value meaning "we don't have it and we don't need it either), and FreeBSD could do similar. Another way were patching the third party program's Makefile accordingly. We should introduce a patches-${OPSYS} directory having precedence before the patches directory of a port. Thus we could maintain our special patches for ports which need them while continuing to use the FreeBSD ports where they work out of the box. I see now that this is already implemented in <bsd.port.mk>, so we could just USE that.
Warner
Regards, Felix.

On Wednesday, October 15, uk1o@rz.uni-karlsruhe.de wrote:
Another way were patching the third party program's Makefile accordingly. We should introduce a patches-${OPSYS} directory having precedence before the patches directory of a port. Thus we could maintain our special patches for ports which need them while continuing to use the FreeBSD ports where they work out of the box. I see now that this is already implemented in <bsd.port.mk>, so we could just USE that.
I've already made a similar message to the ports list. It was shot down. But maybe now that we see the "trouble" with the current setup, we can re-evaluate that. Personally, I think we could share 95% of the ports stuff between open/freebsd, but it would be nice to have the ability to fix things in a local cvs tree, without having to wait for the fix to go through channels. --Toby. *----------------------------------------------------------------------------* | Tobias Weingartner | Email: weingart@BrandonU.Ca | Need a Unix sys-admin? | | 6B-1137 Lorne Ave. |-----------------------------| Send E-Mail for resume, | | Brandon, Canada | Unix Guru? Admin, Sys-Prgmr | and other details... | |----------------------------------------------------------------------------| | %SYSTEM-F-ANARCHISM, The operating system has been overthrown | *----------------------------------------------------------------------------*

In message <14196.876929326@natasha.brandonu.ca> Tobias Weingartner writes: : I've already made a similar message to the ports list. It was shot down. : But maybe now that we see the "trouble" with the current setup, we can : re-evaluate that. Personally, I think we could share 95% of the ports : stuff between open/freebsd, but it would be nice to have the ability to : fix things in a local cvs tree, without having to wait for the fix to go : through channels. I would like to support this 100%. This would also help with the -lcrypt problem, et al. Recall that bsd.port.mk already supports this. We can start doing it right away... Warner
participants (3)
-
Tobias Weingartner
-
uk1o@rz.uni-karlsruhe.de
-
Warner Losh