From owner-freebsd-current Sat Feb 19 23:31:54 2000 Delivered-To: freebsd-current@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id AC71937BE57; Sat, 19 Feb 2000 23:31:51 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id XAA58754; Sat, 19 Feb 2000 23:31:42 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Kris Kennaway Cc: Victor Salaman , freebsd-current@FreeBSD.ORG Subject: Re: openssl in -current In-reply-to: Your message of "Sat, 19 Feb 2000 20:40:39 PST." Date: Sat, 19 Feb 2000 23:31:42 -0800 Message-ID: <58727.951031902@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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