Ainsi parlait Buchan Milne :
> Stefan van der Eijk wrote:
> > actually, we should try to get some agreement on packaging standards
> > with RedHat, or at least, with their contributors, so that at least
> > these "contrib" archives can be merged...
> >
> > or am I being the idealist again?
>
> Apparently jpackage has had some success in this kind of thing ...
> Guillaumovitch?
This success has a heavy cost however, as all distribution-specific features
have to be at best isolated in a distribution-specific subpackage (as menu
entries for instance), at worst dropped completly. It also needed to backport
to redhat a lot of advanced utils, as update-alternative, or mdk-specific rpm
macros too. And worst of all, it forced us to express many dependencies as
files instead of packages, as they don't have the same name/granularity from
one distribution to another.
This only consider of course spec files compatibilit, not build packages
compatibility, as spec-helper have different behaviour from one distribution
to another, compilations flags change also, etc...
Actually, the more i have experience in packaging, the more i am convinced
than genericity is directly antagonist to integration. As soon as you have
something complex (a server, for instance), if you really want to have it
running out of the box, you are forced to either support only one
distribution and one version, or use so many test case that it soon becomes
unmaintainable.
Despite this extreme situation, it is also true than the more standardisation
we have, the less work we have for porting/syncing packages coming from
outside world. AndI think the best tool for this is definitively an explicit
policy, such as the mdk rpm howto, that we need to extend, clarify and
publicize as most as possible, even among unb^H^H^Hnon-mdk users.
--
If such a program has not crashed yet, it is waiting for a critical moment
before it crashes.
-- Murphy's Computer Laws n�6
