On Sun, 29 Feb 2004, Georg Schwarz wrote:

> I'm installing pkgsrc/net/ntp4 on IRIX 5.3. Basically, almost everything
> is fine out of the box except for some minor problems:
>
> ntp-keygen, ntptime, and tickadj are not built on IRIX, but timetrim is.
> Can PLIST and the installation process be made to reflect this?

Yes. I suppose we have to split the PLIST into PLIST.common, and
PLIST.${OPSYS} for every supported ${OPSYS}.

> For ntptime the decision made by configure seems less straight-forward,
> so don't know which platforms are affected (or whether, for example, it
> should actually compile on IRIX).

The change was made in the ntp sources when "timetrim" was added,
so... is it safe to assume "timetrim" does it all on Irix 5? That
would be more on-topic in an NTP discussion forum, in any case.

> The following entries from PLIST are affected:
>
> bin/tickadj
> share/doc/html/ntp4/tickadj.html (maybe to add anyway?)
> bin/ntptime
> share/doc/html/ntp4/ntptime.html (maybe to add anyway?)
>
> one would have to add bin/timetrim

> Why ntp-keygen is not made I don't know. It seems not to figure that I
> do have openssl. From config.h:
>
> /* Use OpenSSL? */
> /* #undef OPENSSL */
>
> I had to add the following lines to the top-level Makefile in order to
> make it use openssl and compile ntp-keygen:
>
> CONFIGURE_ARGS+=  --with-openssl-incdir=${SSLBASE}/include
> CONFIGURE_ARGS+=  --with-openssl-libdir=${SSLBASE}/lib
> CONFIGURE_ARGS+=  --with-crypto=openssl
>
> I wonder why this is necessary?

Is this with the package OpenSSL? I'm led to believe that "buildlink"
was supposed to take care of such things, but the package doesn't
build at all if you simply uncomment USE_BUILDLINK2=YES, and now
there's buildlink3...

Do we even want this package to ever build against package OpenSSL for
platforms that don't ship OpenSSL in the base system? It would avoid
a lot of problems, but if the new crypto features are the chief reason
to upgrade, then I suppose that's not an option?

> Another issue is that IRIX's find does not support -print0. Do we really
> need that here? Are there in fact any files whose names contain
> whitespace characters? Changing it into -print (and leaving out the -0
> for ${XARGS} did not lead to any immediately obvious problems for me at
> least.

I guess so. I originally made all the mod and permission changes in
the build directory, and then pax'd then into place, but the vision
has been chipped away at in order to support folks who "make install"
as root but can't "make clean" as root, and to support linux, so what
the heck. The only danger seems to be from rogue root users who set
traps for other root users, and you can't secure against that
possibility very well anyway.

> PS: should I rather submit a formal bug report?

Please.

Frederick