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: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Hi Andreas,
Andreas Hanke andreas.hanke@gmx-topmail.de writes:
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 Hanke andreas.hanke@gmx-topmail.de [Oct 21. 2006 20:36]:
This is a short specification of requirements for a consistent repository.
Is _a_ consistent repository desirable ?
Probably not. The consistency requirement is only on the client side, the set of repositories as seen by the client should be consistent.
So I'll comment on your specification with a set of repositories in mind.
(1) All requirements of binary packages must be provided by a binary package.
Beware. There are hard (requires) and weak (recommends) requirements. Only the hard requirements must be provided (or weakened ;-))
(2) All build-requirements of source packages must be provided by a binary package.
Agreed.
(3) The SOURCERPM tag of every binary package must exactly match an existing source package.
Agreed.
(4) All packages which are provided for more than one architecture should be provided with the same version and release numbers on all architectures.
This is indeed desirable but not feasible in the real world. For example, sun-java is not available for all architectures. On SLES, we ship ibm-java for some 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.
Agreed. Use 'conflicts' to express mutually exclusive packages.
(6) No file in the distribution may be provided by more than one package unless all its providers are marked as conflicting.
RPM (and the dependency solver) take care of this. There is no need for an explicit conflict.
(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.
Sound more like an rpm bug to me ;-)
(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).
This is probably very hard to check.
For every rule given above, we should find means to verify/enforce it. This might be the hardest part of this proposal.
Klaus --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-
Andreas Hanke -
Andreas Jaeger -
Klaus Kaempf