Date: Sat, 19 Feb 2000 23:31:42 -0800 From: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> To: Kris Kennaway <kris@FreeBSD.ORG> Cc: Victor Salaman <salaman@teknos.com>, freebsd-current@FreeBSD.ORG Subject: Re: openssl in -current Message-ID: <58727.951031902@zippy.cdrom.com> In-Reply-To: Your message of "Sat, 19 Feb 2000 20:40:39 PST." <Pine.BSF.4.21.0002192023290.3894-100000@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> Well, you're the release engineer of course..but I don't think the
> problems are insurmountable. Sysinstall could be made to install the
> correct package after asking the user the right questions (if they choose
> to install crypto):
Again, I simply do not wish to depend on any more packages from
sysinstall. I'm not trying to be difficult here, it's simply a fact
that they:
1) Make my QA process a lot more difficult and error-prone.
I don't get to build them myself, I can't fix really them
myself if they break, I just plain don't have any control over
the circumstances under which such packages are built (in a
clean chroot tree, a freshly installed box, whatever's
necessary to ensure they're "clean") and that really bothers
me. With the distribution tarballs, it's very clear to me
just how every piece is built and I have a thread to follow
if (when) something breaks.
2) Cause me version-sync problems for sysinstall when things
off in ports-land change and it requires someone who knows
that sysinstall depends on these things to go look at syncing
things up again. Since that's currently mostly just me, I
represent a single point of failure when I forget. :)
3) Cost me (us) valuable testing time when I've got a release
snapshot ready to go but no up-to-date package(s) which are in
sync with it (say a header or library it depends on has
changed). If it takes 4 of us to produce "a release" then
we've lost a lot of the advantage we gained by automating it in
the first place and make it that much more difficult to
coordinate the release of one.
This essentially underscores a point I've also made many times: There
is a very fuzzy division between /usr/src and /usr/ports and that fact
costs us every time this sort of thing comes up. If you start
depending on ports from src, you both make the lines even fuzzier and
you make the entire release building process no more robust than the
weakest part of the build chain. In the case of the docports, for
example, that part of the chain has often been very weak indeed and
frequently requires setting NODOC=YES by default or I don't get any
snapshots done at all for long periods of time. If I have to do the
same thing for crypto, I've just doubled my exposure and the amount
of tarball download time a make release already requires.
If you see a better way out of this, I'm all for hearing about it.
All I've done with sysinstall so far is set USA_RESIDENT=YES in
/etc/make.conf now if you select Yes at the DES distribution menu
(which is already covered with all kinds of legal disclaimers).
- Jordan
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?58727.951031902>