Hi Manoj, On Freitag, 7. August 2009, Manoj Srivastava wrote: > On Fri, Aug 07 2009, Holger Levsen wrote: > > Today I picked another simple category: packages which failed the > > piuparts test because the package tries to overwrite another packages > > files without declaring a conflict or replaces relation. See policy 7.4 > > and 7.6 at > > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts > > and > > http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
I've changed this text now: s/a conflict or/ and also removed the reference to policy 7.4, since conflicts are not enough to prevent the problem of a package trying to overwrite anothers files. > While it is good to discover these bugs, is puiparts the correct > place to do this check? Won't puiparts only report on packages > installed on the machine on which the test is run, and thus miss any > conflicts on packages not currently installed? The piuparts tests on piuparts.d.o are run in clean chroots. http://piuparts.debian.org has more info on the setup. > Also, shouldn't dpkg also complain about installing a package > with conflicts? And thus if one were running puiparts on one's new > package, one would already know about this when one installed the > package on the machine on testing? > > I guess I am somewhat confused. Is this puiparts test telling me > something I would not learn anyway when I install my package for > testing? Not really, especially if you run piuparts yourself before uploading ;) And of course you can also manually do what piuparts does. But not every package is maintained by someone who does this, some packages even don't have a maintainer anymore :-) piuparts(.d.o) is ment as a tool to catch common problems systematically. > Also, wouldn't a periodic check of the Contents.gz files yield > much more exhaustive results? Yes, the results of that are available at http://edos.debian.net/missing-conflicts/ ;-) regards, Holger
signature.asc
Description: This is a digitally signed message part.
