We really don’t say much about package dependencies in the LSB. LSB packages have strict limitations on the kinds of dependencies they can have; the basic idea is that they depend either on “”lsb” or on other packages provided by the vendor.

I don’t think unifying package namespaces is going to work, mostly because it implies a level of cooperation and deference that isn’t really possible. People have their own ideas for how these things should be done.

Of course, if someone else can manage to pull it off, we wouldn’t mind being proved wrong.

The simple answer is to point to the LSB’s deprecation policy; we can’t just drop things. But that’s not really an answer.

Most ISVs are even less happy with the idea that they must outsource their installation to the distros than they are with RPM.

The last time we got ISVs and distro people in the same room to talk about this problem, they came up with the Berlin Packaging API. But that’s turned out to be controversial as well, especially among those who weren’t at that meeting.

We’ve talked about deprecating RPM support in the past. But some ISVs want to interact with the package manager; before we have something like the Berlin API, I don’t know that we’ll be helping them by simply removing capabilities.

I’m Niklas Andersson, writing for Swedish netmag TechWorld Open Source.

I’ve worked with Red Hat between versions 4.2 and 8.0 during the time when resolving package dependencies was a head ache at best.

With Debian 3.1 I ran into very few problems and with Ubuntu I haven’t had any issues this far (besides some I’m responsible of myself due to my own bad packaging).

My question is: Has LSB mechanisms for resolving package dependencies in a distribution neutral manner?

Without such mechanism I find it difficult to create a one-size-fits-all-standard.

Me personally think that a common namespace (how packages are named) is more important than RPM vs APT.