* Andreas Hanke <[EMAIL PROTECTED]> [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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
