standard dependancy system

[Stanislav Brabec]

Patryk Zawadzki wrote: 
> 2007/11/22, Mildred <ml.mildred593 at online.fr>:
> >
> > The idea was more to provide a standard interface that would be
> > customized by the distribution.
> >
> I'm afraid that the huge success of 0install (or rather lack of it)
> shows there is little to no interest in unifying the system. There are
> also various technical reasons including packaging rules,
> micropackaging and providing multiple versions of same software that
> would make impossible to pick the right thing across all
> distributions. If you need a proof just pick two RPM-based
> distributions and try to install packages from one in the other.

Preparing thousands of packages, I am often thinking about a generic
package description as well.

I can imagine such standard dependency system one level lower: In the
package source level.

1. Developers know all the dependencies of their software (both compile
   time and run time), which of them are optional and which of them are
   mandatory.
2. Developers exactly know, what benefits provide each particular
   optional dependency and they can recommend sub-package splitting.
3. Developers know where to download required software and which
   versions are compatible.
4. Developers know about special actions needed before/after
   installation of their software.
5. Developers know where to look for important crash and security fixes
   for released packages.
6. Developers know, which version is stable and what is the latest
   version URI.
7. Developers know the "packaging paradigm" used (i. e. how to compile
   and install it - automake based, perl based,...)

8. Packager does not know about any of the above and has to guess.


The description shoud say us:
- URLs of home pages of dependent packages.
- Description of optional dependencies and optional features.
- Description of pre/post install scripts and other special actions
  needed.
- Propose package splitting.
- "Packaging paradigm" (each vendor can define their own description,
  how to call "./configure ; make ; make install").
- And yes, optional information can be provided.

It could be a huge help for packaging automation.

I see that for example configure.ac already contain some of these
information, but in a form, which is machine executable, but machine can
not parse and understand it. You can do post-mortem analysis of
config.log and try to guess, what was really needed.

I can even imagine modification of automake to create part of such
meta-description while calling ./configure.

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sbrabec at suse.cz
Lihovarská 1060/12                            tel: +420 284 028 966
190 00 Praha 9                                fax: +420 284 028 951
Czech Republic                                http://www.suse.cz/