Le Ven 23 novembre 2007 13:18, Patryk Zawadzki a écrit : > 2007/11/23, Stanislav Brabec <[EMAIL PROTECTED]>: >> 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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
