Re: Dependencies
From: Michel Talon (talon_at_lpthe.jussieu.fr)
Date: 06/30/04
- Next message: Simon Barner: "Re: winmodem"
- Previous message: John: "Re: 4.10 ISO & Kmail?"
- In reply to: Andrew Reilly: "Re: Dependencies"
- Next in thread: Ben Crowell: "Re: Dependencies"
- Reply: Ben Crowell: "Re: Dependencies"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 30 Jun 2004 08:52:56 +0000 (UTC)
Andrew Reilly <areilly-newspost@areilly.bpc-users.org> wrote:
>
> Can you recommend another ports dependency management system that
> is written in C? I'm sure many people would be keen to have it.
apt-get, it is written in C++. Not that i like it much, but at least
it exists. Personnally i have nothing against ruby, of course.
> In the mean time, though, portupgrade does a really, really good
> job of a large and difficult problem. Since I started regularly
> using it I can count the number of dependency-related breakages on
> the fingers of one hand. One of its most significant and
I don't agree. I have encountered a lot of problems with portupgrade.
> least-mentioned benefits, I believe, is that it keeps old versions
> of libraries around until *no* ports depend on them. It can do
> that, because it knows what everything depends on. Thanks to the
No, and this is my main grief, all these package management systems,
including apt-get, deduce the dependencies from what is said in the
ports files written by the port maintainers. This is bad in my opinion,
because these dependencies are frequently over strict. Another method
would be to use ldd on all binaries in the path to deduce what shared
libraries are really needed and *keep them*. I have been told that
this is what swaret does for Slackware, and people seem to be very happy
with this tool.
> wonders of versioned shared libraries, it's usually possible for
> different applications, that use different versions of the same
> library to co-exist.
Apparently there are cases were the version numbers of the libraries are
not properly bumped and chaos ensues, this is a problem. The Linux
people have introduced versioned symbols in the shared libraries to help
solve this difficult problem.
> The simple, "make deinstall && make install"
> upgrade mechanism doesn't look after dependencies this way, and
> nukes the old versions of shared libraries.
And this is my grief number ONE. Kris Kennaways says that things have
always been this way in FreeBSD, i cannot assert whether this is true or
false, but what i can assert is that i have used make install in ports
for years without encountering any problem. It is only recently, after
the introduction of portupgrade that i have seen problems creeping in.
Make deinstall should never nuke shared libraries under any pretext,
unless formally instructed to do so by the user. I am almost sure it did
not in the past. Disk space is cheap, i could trade any day lost space
for hassle free installation of softs. It is only when two libraries are
incompatible and produce chaos that one of them should be nuked, and
only after agreement of the user. Anyways, for many years FreeBSD has
been the easiest system to manage and keep up to date. Only recently we
see people beginning to complain on various forums. This is not good for
our beloved system, particularly when the kernel is in a "transitional"
state, or said it otherwise, doesn't particularly shine in front of the
Linux kernel.
>
-- Michel TALON
- Next message: Simon Barner: "Re: winmodem"
- Previous message: John: "Re: 4.10 ISO & Kmail?"
- In reply to: Andrew Reilly: "Re: Dependencies"
- Next in thread: Ben Crowell: "Re: Dependencies"
- Reply: Ben Crowell: "Re: Dependencies"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
