[Rpm-maint] Re: [packaging] RFC: Berlin Packaging API

[Edward Welbourne]

> I had a brief look at Opera, but the supplied script does:

> OPERA_BINARYDIR=./bin/

> so it can only be run when the cwd is the opera package, which is a
> bit odd,

Yes.  This script is the one to be run when evaluating a package,
before installing it; a separate script is generated when it's
installed, that doesn't have the hard-wired assumption that it's to be
run from the tar-ball directory.  But, as you say, even this
evaluation script could be modified with reasonable ease to avoid the
problem.

> I know you said previously you were waiting to see what the LSB
> decides upon before spending much time looking at the existing
> packaging systems, but I assume you've done some preliminary
> investigations into the options.

actually, mostly reading this list to find out what the options are !
I have very little time to spend on packaging - and I've now handed it
over to a colleague (with similarly little time), 'though I've been
keeping up attention here - mostly out of habit :-)

> Do you have any requirements that aren't met by Zero Install?

Everything I've seen to date about 0install looks good.  The one area
where I have doubts (which may be more my ignorance than the facts) is
integration with the native packaging system, particularly where it
comes to virtual packages.  In (at least) Debian, packages can declare
that they provide some given virtual package, on which other packages
then depend.  As long as one package that provides the virtual package
is installed, packages that require it are happy.

For example, if the admin installs some package (many *-doc-html
packages in Debian, for example) that depends on there being a web
browser installed, we (or Firefox, as supplied by Mozilla, rather than
the debranded version from the distro) need to have told the system
that there is indeed a web browser installed.  Otherwise, the admin is
forced to install some distro-supplied web browser (e.g. IceWeasel),
that they don't actually need.  The ISV's package needs to be able to
say that it supplies the x-www-browser or www-browser metapackage,
even though it's not part of the distro's system.

Then there are the non-strict dependencies (Recommends and Suggests,
in Debian parlance, as distinct from Requires).  We suggest a flash
plugin, for obvious reasons: but there are several choices of flash
plugin these days, so we'd ideally specify some meta-package,
flash-npapi-plugin, and leave relevant plugins to declare that they
support flash via the NPAPI, by providing this meta-package.
Actually, there's no such meta-package, so we list all of the known
flash plugins (which is sub-optimal, as the suggestion could just as
readilly be met by one we haven't heard of) and leave the user to
chose.  As for flash, so for every other kind of content that relies
on plugins.  There's no way it could make sense for a browser to
deliver all of those things, yet it is worth letting the native
package system know that installing them would improve the user's
experience.

There's some sense to the various approaches that require ISV packages
to ship with the non-LSB libraries on which we depend, but even this
runs foul of cases where there's a legitimate choice: an ISV whose
product depends on a web browser, for example, shouldn't be forced to
chose one and bundle it.  There's probably one installed anyway; and
the distro probably has one available to install if not, so the
package should be able to just ask the distro's package manager to
resolve its need.

	Eddy.