[packaging] RFC: Berlin Packaging API

[Dan Kegel]

On Thu, Feb 28, 2008 at 2:29 AM, Edward Welbourne <eddy at opera.com> wrote:
>  As an ISV's packager, I'd like to point out that maintaining our own
>  installer also sucks: I'm very keen to see some solution that lets us
>  use something more like a "plain old package", and I suspect most ISVs
>  are too.  However, there are problems with "plain old packages", too.
>  Supporting older versions of each distro obliges us to have several
>  builds.  Further, even among distros with nominally the same package
>  format, we've had problems with incompatibilities: we've seen this
>  most with RPM, probably simply because it's so widely used.

At Google, we've been able to avoid having multiple builds for
different versions of distros.  This might be because we're
willing to drop support for old distros, e.g. I don't think we support
RH9 anymore.
Our main pain point has been openssl, but even that hasn't been
too bad; we look for several soname's at runtime, and accept any.
Fortunately we haven't hit any ABI compatibility problems.

>  ISVs want to be able to create one package for use on all distros.  Of
>  course, that's one per CPU type, times one per older edition (e.g. of
>  LSB, but typically it's mostly glibc version that we care about) we
>  chose to continue supporting; but, crucially, it's *not* times one per
>  distro.

Sure.  I don't see any reason why one would need a build per distro.

>  That would also mean that non-distro packages would have a clear
>  reason to follow LSB policy (e.g. only put things under /opt/, bring
>  your own non-core libraries) where, at present, the requirement that
>  we build a distro-specific package ensures that our ballance of
>  incentives is towards acting fully like a distro package
>  (i.e. installing under /usr/ and using the dependency system to ensure
>  all the libraries we need are installed) - all the documentation for
>  the package format tells us that's what to do (because it's the format
>  for distro packages, so its documentation is aimed at distro package
>  maintainers).  That implies being installed by a privileged user, who
>  thus gets to run {pre,post}-{un,}install scripts, which may do
>  pernicious (or incompetent) things.  Make it easier for us to ship
>  packages, that unprivileged users can install, and we'll be happy to
>  let the tools you've provided insist on us living under /opt/.

You're asking for contradictory things here.  Unprivileged users can't
install to /opt.

At Google, AFAIK, our packages live nearly completely in opt;
the only stuff outside /opt is e.g. a symlink in /bin to the binary,
and desktop icons.  (These are rather glaring holes in the LSB; we'd
rather not have to have anything outside of /opt.)

It sounds like perhaps part of the reason you're not doing distro-independent
.deb and .rpm packages is that there isn't good doc for how to do that.
True?  I can certainly vouch for .rpm doc being crappy and hard to find.

>  The other advantage of a cross-distro format for non-distro packages
>  is that it leaves the door open for a distro to develop a newer
>  package format.

I think if we settle the problems with making cross-disro LSB .rpm and .deb
packages, that issue will be moot.
Beware proposals for new package formats.  That way lies madness.
(Except for breakthrough ones like klik.  Once their suckage is reduced,
that kind of thing will be very useful.)
- Dan