Hi Andreas,
Andreas Hanke
This is a short specification of requirements for a consistent repository.
(1) All requirements of binary packages must be provided by a binary package.
(2) All build-requirements of source packages must be provided by a binary package.
(3) The SOURCERPM tag of every binary package must exactly match an existing source package.
(4) All packages which are provided for more than one architecture should be provided with the same version and release numbers on all architectures.
(5) No package may obsolete another package that still exists in the distribution. Only packages which are no longer part of the distribution may be obsoleted.
(6) No file in the distribution may be provided by more than one package unless all its providers are marked as conflicting.
(7) No package may replace something that existed as a directory in at least the direct predecessor of the currently prepared distribution with a file or a symlink or vice versa unless the rpm breakage caused by this is worked around with %pre scriptlets or similar.
(8) Packages that provide the same thing can indicate bugs, and fool the package manager into installing the wrong package. There are cases where providing the same thing in multiple packages makes sense (example: alternative backends for multimedia players), but the tree should be investigated for cases where this does not make any sense and can be dangerous (example: private copies of libraries which also exist as a public library).
(1), (2), (3) and (4) can probably only be verified shortly before the release. Or, checking this now would not make much sense as long as the tree is still in flux.
(5), (6), (7) and (8), however, are things that can be tested at any time. The Beta period which will start very soon is very well suited to squeeze all such issues out.
Ideally, as much of this as possible would be automated, and done in a similar way as a typical testsuite for software packages. I think that (5) and (6) can be completely automated, while (7) and (8) can be identified automatically, but would still need to be looked at manually for evaluation.
Opinions?
We do a lot of this on a daily basis - and during each release - in our build system. Rudi, what do you think? Is there anything that we miss? Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126