Archie Cobbs wrote: > > How will this work for "perl", which is not removed, but is instead > > replaced with a stub shell script? > > Anything that gets overwritten during the normal install process > is already taken care of. We're just trying to get rid of files > which are not installed by 'make installword' but used to be once. > > I.e., if a file is not installed by 'make installworld' then by > definition it's not required for a correctly functioning system.
This won't work for Perl (which is why I picked it as my example). In order to do what you are suggesting, you will need to create a delta between "previously installed binaries" and "currently installed binaries", and remove anything not in the intersection set, but in the set of previously installed binaries. That would include perl and older shared library instances, not just header files that are stale, etc.. Older shared libraries being removed would break things. Older portmap being removed would break the startup scripts that referenced "portmapper" instead of "rpc.bind" -- unless they were *also* overwritten. You overwrite things which are in the intersection set with new binaries. And you install new binariers that didn't exist before: anything not in the intersection set, but in the set of newly installed binaries. The intersection case is problematic, in that you would overwrite your old, real perl with a shell script stub, which also makes perl a good example for this experiment. The last case is not a problem, since it's "new stuff" (of course). Even starting today, if you had a packing list for the next 4.x release, so that you could differentiate what went away from what was not installed from "new stuff", it doesn't help existing installations that are trying to upgrade from source. This has kind of been discussed before; really, you have to teach the binary revision management tools about the base system; for perl, in particular, this lets you install the port version when you know you are upgrading from something with a system version and something with a system stub that doesn't work (really, you want a package version, not a port version, for this -- forcing the build of the package as part of the build of the system, as painful as that sounds). The same thing applied to installing a "compat4" when upgrading from 4.x to 5.x. The user is then free to manually deinstall the "compat4" package, if they do not require it. Personally, I've already been screwed multiple times on libc not having a version number bump, when the X binary distribution for 4.x is attempted to be run on 5.x (the simplest example is the "resize" program, which fails due to undefined symbols). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
