standard dependancy system

[Nicolas Mailhot]

Le Ven 23 novembre 2007 13:18, Patryk Zawadzki a écrit :
> 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.

ROTFL

>> 2. Developers exactly know, what benefits provide each particular
>>    optional dependency and they can recommend sub-package splitting.

ROTFL #2

>> 3. Developers know where to download required software and which
>>    versions are compatible.

ROTFL #3

>> 4. Developers know about special actions needed before/after
>>    installation of their software.

This one is mostly true

>> 5. Developers know where to look for important crash and security
>> fixes for released packages.

ROTFL #4

>> 6. Developers know, which version is stable and what is the latest
>>    version URI.

ROTFL #5

By and large developpers know what works on their systems, because at
some time their distro installed some version or they downloaded a
binary dependency and forgot about it, and are completely clueless
about the rest.

What they know about other systems is mostly feedback from packagers
on those systems.

Developper-defined dependencies tend to be "use the exact version x of
foo because that's what I have on my system and I don't care if it's
obsolete, full of known security holes, or if I patched it locally
because that was easier than report a bug upstream"

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

Packager at least knows reasonable constrains on sane dependencies.
Developper knows "it runs on my system".

>> The description shoud say us:

Yay for yet another layer of poorly defined dependencies that will go
stale faster than you say poof and that will have to be maintained by
packagers anyway

[...]
>> It could be a huge help for packaging automation.
>
> Agreed.

I want a pony too.

You can not define good dependencies if you don't understand distro
packaging systems, and if you do undestand them your level of
indirection is totally useless.

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

So what? Developpers do not test against upstream anyway, do you
really think they set up clean LFS boxes with pristine upstream
versions to check their code? They test against whatever their system
provides. If they have a debian box they'll define debian-oriented
dependencies. If they have a fedora one fedora-oriented deps. And
packagers of other distributions will have to match those deps to
their distribution version levels anyway.

In a developper-oriented world, every app would be distributed in its
own virtualisation image matching the system the developper uses, so
he wouldn't have to think about this stuff at all. If a developper
cared about this stuff he wouldn't be a developper but a packager.

-- 
Nicolas Mailhot