standard dependancy system

Patryk Zawadzki patrys at pld-linux.org
Fri Nov 23 04:18:45 PST 2007


2007/11/23, Stanislav Brabec <sbrabec at suse.cz>:
> 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.

All valid points but software is only maintained for as long as it's
fun to do so. Adding additional requirements to software vendors is
not the best approach until we give them tools to automatically check
and prepare such info.

> 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.

Agreed.

> 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.

As a packager I usually grep .am/.ac files for dependencies but
practice shows that versions there are about 50-50 accurate. Then come
distros like RedHat where often versions of packages in distro do not
match upstream versions because of huge effort put into backporting
downstream.

-- 
Patryk Zawadzki
PLD Linux Distribution


More information about the xdg mailing list