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>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14914.826110441>