Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 13 Feb 2001 16:24:00 +0000
From:      Paul RichardsF <paul@originative.co.uk>
To:        Dag-Erling Smorgrav <des@ofug.org>
Cc:        Warner Losh <imp@harmony.village.org>, Peter Wemm <peter@netplex.com.au>, Daniel Eischen <eischen@vigrid.com>, John Indra <john@office.naver.co.id>, freebsd-current@FreeBSD.ORG
Subject:   Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
Message-ID:  <3A895FA0.25EBC727@originative.co.uk>
References:  <200102130120.f1D1KpU56194@mobile.wemm.org> <200102130131.f1D1VrW33790@harmony.village.org> <xzplmrbmk94.fsf@flood.ping.uio.no>

next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Smorgrav wrote:
> 
> Warner Losh <imp@harmony.village.org> writes:
> > I've had problems in the past going backwards on major versions of
> > shared libaries.  The major problem is that if I have binaries that
> > refer to libc.so.503, then when the major number is reverted back to
> > 5, it is a nop because ld will use libc.so.503 for new binaries.
> 
> When we back down to 5, we add magic to the Makefiles to move
> libc.so.5?? to /usr/lib/compat - that way they're only used when
> needed at runtime, not for linking new programs.
> 
> > What's wrong with shipping with say libc.so.505 in 5.0 and then say
> > libc.so.645 in 6.0?
> 
> Umm, I dunno, except that it'll look weird, but that's just a matter
> of taste.

I actually quite like this idea,  I prefer it to the dropping down to a
single digit.

What happens if there's a critical fix in a -stable branch, we *must*
have the option to bump library versions when we need to and if we
release 5-stable and intend to release 6-stable with libc.so.6 then
you've got problems if you find a showstopper in 5-stable and need to
release a new libc in that branch.

If we have 3 digit library versions then there's always scope to roll
forward library versions on a branch, as long as there aren't more than
99 of them :-)
 
> Of course, what we really need is "mandatory minor numbers", i.e.
> minor numbers that are treated as "I need this version", not as "I
> need this version or newer"... *ducks* *runs*

When we dropped minor numbers I had a worry that we'd run into one of
Windows' greatest problems and we have. Applications that are developed
and tested to work with a particular library might not work with a
different version, we're suffering a worst case scenario of this problem
now but even "fixes" in new versions can cause applications to break and
we've already seen this many times in this iteration of -current.

I think we need some form of version control on libraries so that
applications know whether they're linking with the version they're
designed for and to be able to keep multiple versions around in the
system so all applications continue to work.

I understand the reasoning that Elf doesn't need minor numbers but they
served an useful purpose in maintaining application compatibility that
we now lack. If there isn't any better solution then we should be much
more free and easy in bumping the version number because otherwise we're
storing up problems exactly along the lines that makes Windows so flakey
when you change a dll.

Another issue is that if two versions of a library have the same number
then there's no way to find out which the application was intended to
link against. If the version number is bumped more regularly then you
can scan the filesystem and ldd the binaries to find out whether they
need to be rebuilt against a new library.

Given a lot of negatives and only an asthetic postive library bumping
should take place much more often and moving to a 3 digit number based
on the branch actually makes a lot of sense.


Paul Richards


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?3A895FA0.25EBC727>