* Andreas Hanke <andreas.hanke(a)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(a)opensuse.org
For additional commands, e-mail: opensuse-factory+help(a)opensuse.org