LSB, bi-arch, and package repositories

On Thu, Jul 17, 2008 at 04:52:33AM -0700, Dan Kegel wrote:
> This message describes a real world problem I'm hitting now trying to
> ship Picasa.
>
> Consider the case of an ISV who has a 32 bit
> application who would like to build it once
> and allow users to use their native package manager
> to download the package from the ISV's package repository
> and also notify the user when newer versions are available.

The problem you are considering hasn't been one that we've dealt with,
because most ISV that we've been working with haven't been interested
in making packages available via yum (or apt repositories). You're
the first one who's asked for this kind of coverage.

> I'm looking for both a short-term and a long-term solution.
> Short-term, I'd like Ubuntu to get its *!@$ act together and
> return to the practice of letting 64 bit packages depend on ia32-libs
> to trigger installation of all needed 32 bit compatibility libraries.

So I know you this doesn't solve the automatic update problem (which
let's try to treat as a separate problem while we explore the solution
space), but it may be the easist way to solve this problem is a patch
to the "alien" program that when it is asked to convert a 64-bit RPM
to a 32-bit dpkg, that it does so while adding the right dependencies.

The reason why I say this is that Debian's dpkg development looking in
from the outside, seems to be somewhat disfunctional, and attempts to
add multiarch support to Debian has been highly contentious, to say
the list. So unfortunately, I personally don't have much confidence
in dpkg growing the right support to get true multiarch (or biarch)
support in the short term, and I'm not so sure Ubuntu is going to be
willing to firmly grasp the third rail of Debian packaging politics
and fork dpkg and apt in order address this problem. I could be
wrong, and if I am, I would be delighted, but patches to support
multiarch, at least in a partial way, have been drifting around for
some 3-4 years, and they have never been integrated.

So it may be that submitting patches to alien may be the fastest way
to solve the multiarch problem from practical point of view.

> Long-term, since forcing all distributions to support yum rpm
> repostories is not likely to succeed....

Well, it's not strictly necessary to force switch over to Yum RPM
repositories. Both Debian and Ubuntu (in universe) have Yum packages
available. I can't speak to how well they work, but in theory you a
system could be using yum and synaptics in parallel; it doesn't have
to be an either-or situation.

In the worst case, the shortest path to a solution from Google's point
of view might be to take the yum dpkg, and see if it works properly.
It might need some minor adjustments to use "alien" instead of "rpm"
to install an rpm package, but that would be a relatively minor patch.
I suspect the change to make alien be able to convert 64-bit RPM's to
32-bit dpkg's while adding the right dependencies wouldn't be that
hard, and alien could be taught that when asked to install a package
using -i, to fork off "apt-get install" to fetch any added
dependencies such as the 32-bit libraries.

I suspect it will be easier to get these patches into the alien and
yum packages, since it avoids the dpkg political swamp. (Since dpkg is
so critical, getting consensus to get new features/patches added to
dpkg, even from the original author of dpkg, seems to be glacial, and
there was recently an extremely ugly power struggle which the Debian
ftp masters had to referee as a result of that.)

Until those packages are accepted into Debian and Ubuntu, Google could
include them in its yum repository, and then have Debian and Ubuntu
users simply download and run a simple script which installs the
updated/enhanced yum and alien commands which will do the right thing.
Yes, that's extra work for you, but at least all of the pieces are
under your control. It may be easier than hoping that Canonical will
to fork dpkg, or waiting for the dpkg maintainers to integrate a patch
that has been floating about for years, etc. And it also in the long
term means you only have to release one binary package, which should
save you effort in the long run.

> I'd like the LSB to
> grudgingly accept the .deb format as an alternate representation.

The question is what does it mean for us to "grudgingly accept"? If
an ISV chooses to release an application in multiple formats,
including an LSB-compliant RPM subset (which Ubuntu and Alien's alien
and lsb-install packages know how to accept), as well as a dpkg
version of the application, the "bag of bits" which is the
lsb-compliant RPM would be get the LSB certification mark, and in
practice people would say the application is LSB certified.

If an ISV provides an alternate packaging mechanism for the
convenience of users, I can't see any reason why anyone would
complain. However, giving the the dpkg "bag of bits" the LSB
certification mark doesn't make any sense, since that isn't anything
an RPM distribution could make sense of.

In addition, even if all distributions shipped alien (which can
convert dpkg's to RPM's, although that support is no doubt much less
well tested), in order to add the .deb format to the LSB
specification, we would have to document the low-level dpkg format,
which whould not be a trivial exercise.

So as you say, "back to the real world", it may be the best way
forward is to patch alien and yum to do the right thing on Debian
32-bit systems, and then try to get those changes picked up by the
Debian maintainers. If you can manage do this, then it is highly
likely that Ubuntu will have the support within 6 months. Other
approaches may require you to end up waiting for Godot.....

- Ted