Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 07 Oct 2002 16:00:59 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Archie Cobbs <archie@dellroad.org>
Cc:        "M. Warner Losh" <imp@bsdimp.com>, grog@FreeBSD.org, FreeBSD-current@FreeBSD.org
Subject:   Re: Do we still need portmap(8)?
Message-ID:  <3DA2122B.9276F16@mindspring.com>
References:  <200210072214.g97MEe5M058451@arch20m.dellroad.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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 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?3DA2122B.9276F16>