Hi Andreas, Andreas Hanke <[EMAIL PROTECTED]> 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 Jaeger, [EMAIL PROTECTED], http://www.suse.de/~aj/ SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
pgpTNJAmCLKgW.pgp
Description: PGP signature
