ports/150235: sysutils/smartmontools build system bug

[Kostik Belousov]

The following reply was made to PR ports/150235; it has been noted by GNATS.

From: Kostik Belousov <kostikbel at gmail.com>
To: Alex Samorukov <samm at os2.kiev.ua>
Cc: Garrett Wollman <wollman at freebsd.org>, bug-followup at freebsd.org,
        developers at freebsd.org
Subject: Re: ports/150235: sysutils/smartmontools build system bug
Date: Mon, 6 Sep 2010 11:18:42 +0300

 --xQIvh/8Hgk2AYE+L
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, Sep 06, 2010 at 12:11:35AM +0200, Alex Samorukov wrote:
 >=20
 > >>Thats a good point. I can add SRC_BASE variable to the port, with
 > >>/usr/src as default. E.g. emulators/rtc do this way.
 > >>    =20
 > >There is still no guarantee that arbitrary users will have a copy of the
 > >kernel sources anywhere, or that the copy of the kernel sources they have
 > >somewhere will match the actual kernel running on the system.
 > >  =20
 > In this case smartmontools will run without CISSIO support. I don`t see=
 =20
 > any problems there.
 > >It's also not inconceivable that someone would want to build a port (and=
 /or
 > >make it a package) on another machine than they one they intend to run i=
 t=20
 > >on,
 > >with different kernel versions on both machines.
 > >  =20
 > If kernel versions will be different then probably port will simply fail=
 =20
 > to work, and its absolutely correct behavior.
 > Format of ioctl calls is different in different kernel versions and=20
 > smartmontools heavily depends on it.
 > >Not to make your life difficult, but depending on the kernel source tree=
  is
 > >not a very good idea.  Is there any particular reason the kernel interfa=
 ces
 > >you're relying on are not in /usr/include?
 > Because file cissio.h is simply not exists in /usr/include.
 > >Maybe arguing for the headers you
 > >need to be installed and made available to userspace applications would=
 =20
 > >make
 > >more sense than ensuring your application will break in any of a number =
 of
 > >cases?
 > >  =20
 > If i will include this header to the ports than its very easy to break=20
 > the package in case of ciss driver changes in the kernel. So i`m not=20
 > sure that its an option.
 
 What was proposed by Philip is to install the required include file into
 the standard /usr/include, not to provide it with port. To (hopefully)
 reduce the flame, please test the following patch. If it works for you,
 I will merge it to RELENG_8 and RELENG_7 quickly.
 
 Thanks.
 
 diff --git a/include/Makefile b/include/Makefile
 index 4e7fd93..c1b6245 100644
 --- a/include/Makefile
 +++ b/include/Makefile
 @@ -39,7 +39,7 @@ LDIRS=3D	bsm cam geom net net80211 netatalk netgraph neti=
 net netinet6 \
  	sys vm
 =20
  LSUBDIRS=3D	cam/ata cam/scsi \
 -	dev/acpica dev/an dev/bktr dev/firewire dev/hwpmc \
 +	dev/acpica dev/an dev/bktr dev/ciss dev/firewire dev/hwpmc \
  	dev/ic dev/iicbus ${_dev_ieee488} dev/lmc dev/mfi dev/ofw \
  	dev/pbio ${_dev_powermac_nvram} dev/ppbus dev/smbus \
  	dev/speaker dev/usb dev/utopia dev/vkbd dev/wi \
 
 --xQIvh/8Hgk2AYE+L
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.10 (FreeBSD)
 
 iEYEARECAAYFAkyEo+IACgkQC3+MBN1Mb4imnwCePJOkU5z30gdWW5mTHUjBQPaZ
 LIUAnjp3pe7nXjlbQ0d92zhxN9vEDu1F
 =XFgx
 -----END PGP SIGNATURE-----
 
 --xQIvh/8Hgk2AYE+L--