Re: Dependency hell
Ziller, James [EMAIL PROTECTED] writes: Making a simple symlink from libexpat.so.4 to libexpat.so.5 will allow xterm to run again - but of course that's a dirty disgusting way to do things. From what I understood, pkgdb is the tool to fix this, but running pkgdb -F will not prompt me to change xterm dependencies from libexpat.so.4 to libexpat.so.5. No, that's not the tool to fix it. As /usr/ports/UPDATING would tell you, do a portupgrade -fr textproc/expat2. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Dependency hell
So in other words I do have to recompile everything that depends on a given library just because that library is updated to a slightly newer version?:( jz -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, April 19, 2004 9:20 AM To: Ziller, James Cc: '[EMAIL PROTECTED]' Subject: Re: Dependency hell Ziller, James [EMAIL PROTECTED] writes: Making a simple symlink from libexpat.so.4 to libexpat.so.5 will allow xterm to run again - but of course that's a dirty disgusting way to do things. From what I understood, pkgdb is the tool to fix this, but running pkgdb -F will not prompt me to change xterm dependencies from libexpat.so.4 to libexpat.so.5. No, that's not the tool to fix it. As /usr/ports/UPDATING would tell you, do a portupgrade -fr textproc/expat2. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dependency hell
In the last episode (Apr 19), Ziller, James said: So in other words I do have to recompile everything that depends on a given library just because that library is updated to a slightly newer version? :( If you want those dependant programs to use the new library, yes. It's not required though. When you upgrade a port, portupgrade sticks its old shared libraries in /usr/local/lib/compat/pkg so old binaries still run. It's up to you to manually clean it out occasionally (I just checked and mine is 400MB, with files going back to 1999 :) -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dependency hell
Ziller, James [EMAIL PROTECTED] writes: So in other words I do have to recompile everything that depends on a given library just because that library is updated to a slightly newer version?:( Yes. The developers of the library chose not to maintain backward compatibility. Fortunately, this type of occurrence is rare. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dependency hell
On Apr 19, 2004, at 10:28 AM, Ziller, James wrote: So in other words I do have to recompile everything that depends on a given library just because that library is updated to a slightly newer version?:( Well, you could simply use the old version of the library. It's not especially hard to write code in a way that maintains upwards compatibility-- putting a version # or sizeof(struct foo) in structures being passed around helps!-- but some projects don't bother. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Dependency hell
So then is there a way that the ports/package system can automatically handle replacing libfoo.so.3 with libfoo.so.4, so that packages compiled to use libfoo.so.3 can use libfoo.so.4 instead (assuming the new version is backward compatable)? Or can the port link against say libfoo.so (which should be a symlink to the version of the library that's installed)? Thanks for the responses, James -Original Message- From: Charles Swiger [mailto:[EMAIL PROTECTED] Sent: Monday, April 19, 2004 1:18 PM To: Ziller, James Cc: '[EMAIL PROTECTED]' Subject: Re: Dependency hell On Apr 19, 2004, at 10:28 AM, Ziller, James wrote: So in other words I do have to recompile everything that depends on a given library just because that library is updated to a slightly newer version?:( Well, you could simply use the old version of the library. It's not especially hard to write code in a way that maintains upwards compatibility-- putting a version # or sizeof(struct foo) in structures being passed around helps!-- but some projects don't bother. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dependency hell
On Mon, Apr 19, 2004 at 01:34:34PM -0500, Ziller, James wrote: So then is there a way that the ports/package system can automatically handle replacing libfoo.so.3 with libfoo.so.4, so that packages compiled to use libfoo.so.3 can use libfoo.so.4 instead (assuming the new version is backward compatable)? You can't assume that. The version numbers of libraries are only supposed to be changed when the new version is *NOT* backwards compatible with the old. I.e. libfoo.so.4 is most likely not completely compatible with libfoo.so.3 and any programs that are compiled against libfoo.so.3 need to be recompiled to use libfoo.so.4 Or can the port link against say libfoo.so (which should be a symlink to the version of the library that's installed)? Thanks for the responses, James -Original Message- From: Charles Swiger [mailto:[EMAIL PROTECTED] Sent: Monday, April 19, 2004 1:18 PM To: Ziller, James Cc: '[EMAIL PROTECTED]' Subject: Re: Dependency hell On Apr 19, 2004, at 10:28 AM, Ziller, James wrote: So in other words I do have to recompile everything that depends on a given library just because that library is updated to a slightly newer version?:( Well, you could simply use the old version of the library. It's not especially hard to write code in a way that maintains upwards compatibility-- putting a version # or sizeof(struct foo) in structures being passed around helps!-- but some projects don't bother. -- -Chuck ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Dependency hell
On Apr 19, 2004, at 2:34 PM, Ziller, James wrote:
So then is there a way that the ports/package system can automatically
handle replacing libfoo.so.3 with libfoo.so.4, so that packages
compiled to
use libfoo.so.3 can use libfoo.so.4 instead (assuming the new version
is
backward compatable)?
If the new version of the library is backwards-compatible, it ought to
be installed as libfoo.so.3 (not .4), and yes, the ports system will
handle such upgrades in place just fine.
In particular, OpenSSL (aka libssl.so.n) is an example of a library
that has had many bugfiles and updates without changing version numbers
often. You don't need to recompile everything that depends on libssl
when you update libssl.
People (should) only bump shared library numbers when the library's
interface changes in an incompatible fashion. When that happens, it's
a bad idea to try to fake the system out (say by symlinking libfoo.so.3
to .4): programs tend to crash when you try, or do worse things such as
corrupt data or mishandle authentication and thus open up a security
hole.
Or can the port link against say libfoo.so (which
should be a symlink to the version of the library that's installed)?
libfoo.so is normally a symlink to the latest version of a particular
shared library. A port that genuinely doesn't care which version of
libfoo you have doesn't need to depend on a particular version #, and
you'd see a line in the Makefile like:
LIB_DEPENDS= foo:${PORTSDIR}/misc/foo
...but most ports end up with more specific dependencies (ie, foo.3).
Maintaining backwards compatibility is not a high priority of the ports
system and the result is that people end up recompiling a lot of stuff,
but it's not easy to provide better solutions to this problem.
--
-Chuck
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Dependency hell - fixed
Thanks a lot for all the advice and explanations. My system is now back in
working order after hours of recompiling, now I know how to avoid this mess
to begin with!
-jz
-Original Message-
From: Charles Swiger [mailto:[EMAIL PROTECTED]
Sent: Monday, April 19, 2004 2:05 PM
To: Ziller, James
Cc: '[EMAIL PROTECTED]'
Subject: Re: Dependency hell
On Apr 19, 2004, at 2:34 PM, Ziller, James wrote:
So then is there a way that the ports/package system can automatically
handle replacing libfoo.so.3 with libfoo.so.4, so that packages
compiled to use libfoo.so.3 can use libfoo.so.4 instead (assuming the
new version is
backward compatable)?
If the new version of the library is backwards-compatible, it ought to
be installed as libfoo.so.3 (not .4), and yes, the ports system will
handle such upgrades in place just fine.
In particular, OpenSSL (aka libssl.so.n) is an example of a library
that has had many bugfiles and updates without changing version numbers
often. You don't need to recompile everything that depends on libssl
when you update libssl.
People (should) only bump shared library numbers when the library's
interface changes in an incompatible fashion. When that happens, it's
a bad idea to try to fake the system out (say by symlinking libfoo.so.3
to .4): programs tend to crash when you try, or do worse things such as
corrupt data or mishandle authentication and thus open up a security
hole.
Or can the port link against say libfoo.so (which
should be a symlink to the version of the library that's installed)?
libfoo.so is normally a symlink to the latest version of a particular
shared library. A port that genuinely doesn't care which version of
libfoo you have doesn't need to depend on a particular version #, and
you'd see a line in the Makefile like:
LIB_DEPENDS=foo:${PORTSDIR}/misc/foo
...but most ports end up with more specific dependencies (ie, foo.3).
Maintaining backwards compatibility is not a high priority of the ports
system and the result is that people end up recompiling a lot of stuff,
but it's not easy to provide better solutions to this problem.
--
-Chuck
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
