Date: Tue, 04 Mar 2003 03:12:50 +0100 From: Matthias Andree <ma@dt.e-technik.uni-dortmund.de> To: Joe Kelsey <joek@flyingcroc.net> Cc: John Polstra <jdp@polstra.com>, ports@FreeBSD.ORG, joek@mail.flyingcroc.net Subject: Re: WARNING: portupgrade considered harmful Message-ID: <m3znobubfh.fsf@merlin.emma.line.org> In-Reply-To: <1046491234.458.53.camel@zircon> (Joe Kelsey's message of "28 Feb 2003 20:00:34 -0800") References: <3E5FB1F8.4050405@mail.flyingcroc.net> <3E5FD22B.3040904@mail.flyingcroc.net> <200302282148.h1SLm8pc031639@vashon.polstra.com> <3E5FEE23.8050403@mail.flyingcroc.net> <200303010232.h212WkFj000353@vashon.polstra.com> <1046491234.458.53.camel@zircon>
next in thread | previous in thread | raw e-mail | index | archive | help
Joe Kelsey <joek@flyingcroc.net> writes: > I consider the loading of duplicate, gratituitous libraries differing > only by version number to be a similar fault. I am willing to let that > go as possibly too much of a linuxism, but I really do not like it. I > do not recall it ever being a problem on solaris, probably because they > didn't overuse explicit numeric linking that way people seem to do on > FreeBSD. I personally think that there is far too much dependence on > using explicit library version numbers, causing horrid problems for > upgrading. Well, the "horrid problems" depend on the care of the port maintainer and the upstream maintainer of the library. For example, to mention a lousy (IMO) job, was that the gdbm update between 1.8.0 (which installed libgdbm.so.2) and 1.8.3 (which installed libgdbm.so.3) caused this kind of trouble; the maintainer justifies not bumping the gdbm version to 2.0.0 or 3.0.0 by "only the ABI changed, not the API". However, this still means every port and package that used to depend on gdbm 1.8.0 needs to be recompiled for 1.8.3 (they fixed critical bugs in the update...). I don't know what they thought about the update, and I don't really want to discuss this with people who think bumping the least significant component of a version suits or satisfies ABI changes. It's just unsensible -- and lets libgdbm.so.2 and up in /usr/local/lib/compat/something/ This alone is reason for grief enough, not even taking your dlopen-vs-loader-time-linking issue into account. If I am a direct user of gdbm.so.2 and some other library I use depends on gdbm.so.3, the crash is imminent. I'm wondering, on the ports issue, if a port should be frozen and renamed freetype-2.0.something and a new port be made when the upstream bumps the library's version or changes the ABI or API or anything else of matter. > Of course, I think that this is a very thorny issue. I think that the > dlopen versus linker reference problem still exists and is a very real > bug. The loading of multiple libraries based on number is something I > consider a bug, but I agree to disagree with you on that. Is the dlopen()-vs.-ld.so issue something that can easily be solved at all? My ignorant view is that dlopen() is userspace and ls.so rtld elf whatever reeks of half-kernel half-user. -- Matthias Andree To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m3znobubfh.fsf>