Re: Fast releases demand binary updates.. (Was: Release schedule for 2006 )

On Wed, 21 Dec 2005 20:39, Brian Candler wrote:
> I recently tried to upgrade Mozilla from 1.0.7 to the current ports version
> (1.5.something) on a FreeBSD 5.4 box. This fell over in all sorts of ways,
> and I ended up having to portupgrade almost everything. That then broke me
> in all sorts of other ways, like finding that 'unison' was upgraded and its
> protocol was no longer compatible with 'unison' on other systems, so they
> needed upgrading too. Plus I had to remember to abort the upgrade before it
> started rebuilding openoffice, to avoid my system becoming polluted with
> java...
>
> I have no problem with libraries called libgtk.so.400 or whatever, but the
> whole point of this scheme is that it should be possible to have multiple
> versions installed at the same time.

In an ideal world this would all Just Work (tm).
Unfortunately, developers don't have infinite resources so you experience 
problems like you are seeing.

It doesn't help that there is almost no binary compatibility between various 
releases of libraries (GNOME is really good for doing this in my experience).

> So, if the new Mozilla port really requires the newest version of gtk, then
> it should simply go build that version of gtk and install it alongside my
> existing version, so all the ports linked against the older versions
> continue to work. Setting FORCE_PKG_REGISTER might do this, but if that
> works so well, why is it not the default? And then there are various flags
> to portupgrade / pkg_install which explicitly tell them to leave stale
> versions of shared libraries around, 'just in case' they are needed.

I think the reason it isn't the default is because it pollutes your disk with 
multiple copies of things that may not be necessary. In a lot of cases it 
will cause weird errors (eg one binary ends up with more than one version of 
a library linked to it at run time because its dependents weren't all 
upgraded)

> I think Dragonfly have some good ideas, like using the filesystem to build
> a virtual library environment on the fly. That is, when an application runs
> it sees a /lib directory populated with only the libraries it needs, and
> the exact versions of them. Extending this so that it is possible to have
> multiple versions of the same application (/usr/bin/foo) installed, for
> instant upgrade and rollback, would be even better. (I know there are
> existing solutions which install lots of symlinks, and some ideas can
> probably be taken from those too)

I don't see how this can fix the problem where you have a program that depends 
on 2 libraries and each of those depend another library. If they are linked 
to 2 different versions of that 3rd library you can get very odd behaviour.

This *is* an annoying problem, but the solutions are far from simple..
(Lots more man power would help)

-- 
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
  -- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C