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?

Andreas Hanke
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to