Date: Wed, 06 Mar 1996 03:07:21 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Mark Murray <mark@grondar.za> 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 Message-ID: <14914.826110441@time.cdrom.com> In-Reply-To: Your message of "Wed, 06 Mar 1996 11:42:31 %2B0200." <199603060942.LAA29420@grumble.grondar.za>
index | next in thread | previous in thread | raw e-mail
> 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. Jordanhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14914.826110441>