Re: ZeroInstall & Package systems [Was: Re: Dock padding_pixels suggestion]

On 2007-07-11, Thomas Leonard <[email protected]> wrote:
> If you want to convert XML to a more friendly format, there are other tools
> for that:

But that's once again more work for editing XML than a decent format,
unless the text editor automatically does the conversion... but then
we're back at this: the format could just as well be binary, and
hence more efficient. XML is pointless.

> It uses the 'dependency injection' model (AKA 'inversion of control').
> Instead of each component finding its dependencies (e.g. by searching
> /usr/lib), each component is told where to find its dependencies. So, this
> is an input to the 'svn' component, telling it which 'libsvn' to use.

I was more after the practical aspects of creating a package and
defining dependencies for it, but good to hear that. (Present
handling of library deps is mess down to gcc itself.)

> Or, in a really ideal world you wouldn't have to specify the binding
> method at all, because there would be a standard way to tell a component
> where its libraries are.

In my capability system, the package providing the depended-upon
capability tells how it provides the capability, the information
provided or mechanisms used having been specified by the capability
author. So you'd have something like

  [provided.capabilities.libfooAPI]
  uuid = zxc09z87df890asasödklfj-w3,j.4324asdf08972342340+89sdfadsf9872etc.
  library-file = $PREFIX/lib/libbar.so

in 'libbar' that provides what is locally known as "libfooAPI" and 
globally referenced to with the given uuid that would include the
public key for that capability and a signature by the private key.
The program requiring the capability/library would have something like:

  [required.capabilities.libfooAPI]
  uuid = zxc09z87df890asasödklfj-w3,j.4324asdf08972342340+89sdfadsf9872etc.
  how = link-against $library-file

Alternatively 'how' could be in libbar. Having it in the package requiring
the capability adds an additional test that the capability is of the
requested form, while having it in the package providing the required
capability allows for alternative implementations. Or perhaps whichever
is first encountered should be used, which allows for user overrides of
autodetected settings, as in the autoconf replacement build system draft
at [1].

'link-against' should be a standard feature of the integrated build
system as well as binary package distribution system, although additional
actions should be definable, e.g. in the form

  [actions.gcc-local.link-against]
  ext-objects = $ext-objects $1

  [actions.gcc-bindist.link-against]
  # nothing

  [actions.bindist.link-against]
  LD_PRELOAD = $LD_PRELOAD:$1

Or perhaps 'how = append LD_PRELOAD $1' etc. for a simpler language.
Also 'how' in the original capability requirement could be defined
separately for different targets. Lots of design decisions still
to be made, and use cases to be researched.. not a one man job
this, really. Few things are, and yet just a handful of people 
with a tunnel vision seem to define the direction of the core
FOSS projects that everyone has to suffer from...

  [1]: http://iki.fi/tuomov/b/archives/2006/07/04/T21_20_46/

-- 
Tuomo