* 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