Re: dpkg -L (was: Re: conflicts with libcap-dev)
>>>>> "Martin" == Martin Waitz <tali@rommelwood.de> writes:
Martin> one had to ensure the Conflicts: header to be correct.
Martin> at least for debian-native packages this can be checked by
Martin> dinstall/katie/whatever. it could maintain an
Martin> all-packages/all-files list and check that no file is in
Martin> two non-conflicting packages.
That would be good, if it were done.
Martin> perhaps that is already done, don't know.
Not that I am aware of.
Martin> but you are right: it would be very difficult for
Martin> non-debian partys to keep their Conflicts in sync with all
Martin> debian packages.
...then consider non-Debian packages, eg. Helix code.
(of course you could argue that Debian doesn't support these, but I
think we should support a scalable infrastructure that allows use of
non-Debian packages without disadvantage.)
Martin> perhaps we should provide a stand-alone conflicts-checker
Martin> (addition to lintian, whatever) a list of all files in all
Martin> packages should already be there, for autoapt, right?
Well, it would have to check that conflicts between debs compiled
from the same source package (probably unlikely but still should
be done).
Checking for previous versions of the package might be difficult though.
Perhaps if you limited it to just checking conflicts for last
stable version, last testing version, and last unstable version
that would be good enough though.
At least that should pick up on files being moved between packages,
which seems to be the most common cause of problems.
The big problem I see is that down loading the complete contents[1]
listing for stable, testing, and non-stable will chew up a lot of
bandwidth, especially without rsync. Doing it as a check by dinstall
or something might be better.
Still, something like this might be worthwhile. What do others think?
Note:
[1] complete listing of files in distribution + Packages file so
conflicts can be looked up.
--
Brian May <bam@debian.org>
Reply to: