From owner-freebsd-current Wed Mar 6 03:08:44 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id DAA11836 for current-outgoing; Wed, 6 Mar 1996 03:08:44 -0800 (PST) Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id DAA11823 for ; Wed, 6 Mar 1996 03:08:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.7.4/8.6.9) with SMTP id DAA14916; Wed, 6 Mar 1996 03:07:22 -0800 (PST) To: Mark Murray cc: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch), freebsd-current@FreeBSD.org (FreeBSD-current users) Subject: Re: 2.2-960226-SNAP now on ftp.freebsd.org In-reply-to: Your message of "Wed, 06 Mar 1996 11:42:31 +0200." <199603060942.LAA29420@grumble.grondar.za> Date: Wed, 06 Mar 1996 03:07:21 -0800 Message-ID: <14914.826110441@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-current@FreeBSD.org Precedence: bulk > I found out why last night. The make world is "allowing" this to happen > by not having a -DNOCRYPT in release/Makefile release: target. We should > have some cruft a' la the eBones crap for explicitly generating the crypto > versions. I am working on that now - init is done - ed will come tonight > along with the changes to lib/Makefile and some others. Awesome! Thanks, Mark! > Why are we carrying some of this crap? Ok I know why we need the old > shared libraries, but there is a libgcc.so.261.0 in the distribution > that really aught to go in the libcompat set? Let me know what is > involved in broad terms and I'll look at it. Well, as to why, I guess backwards compatibility. People want to continue running their old bins. If there's something from a previous release that needs to go into a new one in order to support this, there's the start of a compat dist. The libgcc.so.261.0 was a special case because Poul-Henning didn't feel like rolling a compat205 distribution with only one file in it.. :-) > Isn't sticking buggy software on a developer's CD an incentive to fix > it? ]:-> That's one way of looking at it, I suppose.. :-) If the XFree86 people actually feel that this would be of value to them, I'll do it. Otherwise, I'll just stick with what's there. Jordan