Date: Fri, 05 Jul 2002 05:22:24 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Sheldon Hearn <sheldonh@starjuice.net> Cc: Paul Richards <paul@freebsd-services.com>, current@freebsd.org Subject: Re: Removing perl in make world Message-ID: <3D258F80.BD86F9D0@mindspring.com> References: <1025862341.1573.40.camel@lobster.originative.co.uk> <20020705095258.GC775@starjuice.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Sheldon Hearn wrote: > On (2002/07/05 10:45), Paul Richards wrote: > > I think we should add a target to make world that checks for the > > existence of an old base install of Perl and removes it if it exists. > > I don't like this idea. There are a lot of funny things one could say at this point... but removing something as part of an install process really needs to be avoided. > > As a general principle, if we do things like remove code during -current > > development then make world needs to cater for that change. The idea of > > make world is that what you get at the end of it is a pristine install > > of a snapshot of FreeBSD from the current branch. This sort of implies that after a "make installworld", a FreeBSD box is magically in a pristine condition -- except for configuration data and configuration defaults, and the password file, and other things in the /etc directory and ... etc.. This might be an OK goal, but as things stand, configuration data is insufficiently seperate from code in FreeBSD, and this is really not an option at this time. > No, the idea of `make world' is to upgrade my system in the way that I > tell it to. > > Having the world target leave perl behind was critical for me when I > upgraded my box. There are amusing things to say about this as well. One point that should be brought up, though, is that the reason perl was diked out if the base system is that perl itself was growing in a rapid and uncontrolled fashion, much like cancer, and there was no such thing as "core perl" without a lot of things that tended to add security holes (e.g. CGI perl modules, etc.). What this basically means is that, whatever you were left with after the install-based upgrade -- it wasn't officially perl. You are probably better off forcing it to be upgraded at the same time. Unfortunately, this isn't automated, and would require major surgery on the install tools to make it so. Diking it out looks more correct; too bad there's not a "prune" option, as in CVS, that is on by default, but can be turned off. > > I'd like to resurrect it's original meaning and add code to clean out > > old versions of Perl. > > This would not fit in with the rest of the world target, which doesn't > clean out stale headers, stale libraries or stale binaries. > Special-casing certain things will surprise people. Headers and libraries arguably should be removed, so as to avoid errors; not ports headers or libraries -- which aren't in the installation target paths in the first place -- but things like deprecated system headers, etc.. Note that this is really problematic, since there are optional install components, such as binary backward compatability libraries that are installed into system directories, such as /usr/lib, that aren't technically the result of the build process itself. Header files under /usr/include are pretty straight forward, as far as that goes, though, unless they overlap components that get installed for binary compatability (I don't think the tools actually support building for this, though, because of crt, manifest constant, and the a,out->ELF change). -- Terry 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?3D258F80.BD86F9D0>