Date: Tue, 22 Oct 2002 14:52:50 -0400 From: The Anarcat <anarcat@anarcat.ath.cx> To: "James E. Flemer" <jflemer@acm.jhu.edu> Cc: freebsd-libh@freebsd.org Subject: Re: updating shared libs Message-ID: <20021022185249.GD3492@xtanbul.espresso-com.com> In-Reply-To: <Pine.LNX.4.33L2.0210221357180.11540-100000@centaur.acm.jhu.edu> References: <Pine.LNX.4.33L2.0210221357180.11540-100000@centaur.acm.jhu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
I don't think this belongs to binup to decide.
As Mark mentionned in a previous mail, binup shouldn't deal with
packaging issues itself. So I'm CC'ing this to libh, and setting
reply-to.
See me comments inline.
On Tue Oct 22, 2002 at 02:07:27PM -0400, James E. Flemer wrote:
> Wow, there is traffic here once again. Anyway, I was
> wondering if anyone has ideas about how one would go about
> replacing shared libs (assuming they are in use by running
> procs). Will doing so cause any problems? I assume that
> renaming a file won't cause problems because the inode is
> preserved, so the VM will still know where the backing
> store is.
I'll answer by explaining a bit how portupgrade works.
portupgrade, when hitting a shared libs it must upgrade, moves it to
${PREFIX}/lib/compat/pkg/, and the new shared lib is installed in
${PREFIX}/lib as usual. lib/compat/pkg is kept in the ldconfig path,
so the old library gets picked up when needed by old packages.
portupgrade suggest cleaning up the compat directory every once in a
while, but I have found it near to impossible without recompiling a
lot of dependent packages.
Apart from that, you're right about the renaming. I think that you
could even *remove* a shared library altogether and *running* process
wouldn't be affected, because the libaray is already open(2)'d.
Of course, new processes wouldn't start because they wouldn't link
properly.
> But what about upgrading something like libjpeg that may be in use
> by lots of programs. How should a binup type program deal with this?
I'll tell you how I think libh will work this out.
libh packages will have 3 dependency specs:
RequiredFeature:
- min version
- prefered version
- max version
If (say) ImageMagick requires libjpeg-2 and only libjpeg-1 is
installed, libh will perform an upgrade of libjpeg-1 to libjpeg-2, if
possible. And this is pretty important. This means that all packages
depending having libjpeg-1 as "max version" will have to be upgraded
too so that they link properly. LibH should take care of this
automatically.
Of course, if the upgraded dependent packages aren't available
anywhere, they will have to be compiled from scratch or the upgrade
will simply fail.
I guess it would be possible to hack this to *force* libh to install
the new libjpeg over the old one, but that's really against libh's
spirit.
> It would be nice if whatever binup process could provide
> patch, rollback, commit type operations to test patches w/o
> committing them on a running system. This would need a safe
> way of messing w/ shared libs w/o breaking stuff though.
libh is designed to have full rollback support. However this is not
completely implemented.
A.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20021022185249.GD3492>