Re: "scala" script and classpaths

On Tue, Feb 07, 2006 at 05:38:20PM +0100, Lex Spoon wrote:
> We seem to agree that it is not sensible to try for packages to be so
> portable that they can coexist with packages developed completely
> independently.

No, I agree that it is difficult, but if we are ever to reach that
fabled utopia that is component-oriented software development, I think
we have to try as hard as we can. And the stuff I mumbled about
dependencies is the approach I'm looking at taking for Kitten.

> Once we abandon this idea of completely portable packages, you end up
> admitting that someone needs to do all the little cleanups necessary
> to make one component work with some other set of components.  Those
> little cleanups are *packaging*, and the resulting sets of packages
> are distributions-- or, as I talk about it abstractly, "package
> universes".  To be precise, a package universe corresponds to one
> stream of development within a Linux distribution, e.g. Debian/sarge.

I recognise that, but the existence of multiple 'universes' in Debian
is one of the reasons I switched to Gentoo. The canonical problem is
simple: I run Testing or Stable, but I want to run a program that is
only available in Unstable. The only way I can use the packaged
program version is to upgrade my entire system to Unstable (apt can be
persuaded to do partial upgrades, but they generally don't work). Why
should I compromise the stability of my entire system just to run a
single possibly-unstable program?

And that's just within one centrally-managed project. Add a couple of
forked projects with their own universes (e.g. Ubuntu), and unless a
herculean effort is made by packagers to support every universe going,
end users are bound to be disappointed.

In practice, I'd skip the package manager and compile my program from
source, and it probably worked, once I'd manually figured out
dependencies. Gentoo avoids the problem by always compiling from
source, so package versions can pretty much be mixed and matched as
you see fit. It has a notion of Slots, which allow multiple versions
of the same package to coexist where necessary (e.g. GTK1 and GTK2).
Conflicts can occur, but they are fairly rare.

Going back to Java, we don't have to be anywhere near as strict as
Debian is, because we have much better ABI compatibility than for
native code. For the most part we /can/ just use the latest binary
version of software and there's a reasonable chance it will work. The
Log4j example I gave is certainly far from unique, but I also don't
think it's so common that it rules out even attempting to have
independent packages coexist. It only means that you can't just stick
everything on the classpath and expect it to work.

> Individual package universes have rules, but they tend to be more
> informal than what a package tool would insist on.  Importantly, the
> rules are different for different groups.  The needs of a 6-person
> collaboration with 10 packages are different than those of a
> Debian-sized collaboration with 10,000 packages.

But is the 10-package universe useful? Won't it be forever expanding,
duplicating the work done in some larger universe? Either that, or
each user ends up needing their own custom universe, with the
particular packages they need, at which point the whole exercise has
gained nothing.

Incidentally, is there more than one sbaz universe at present?

-- Jamie Webb