Incomplete Dependency Parsing about python-deb-pkg-tools HOT 3 CLOSED

Hi Lee and thanks for the feedback!

First of all, thank you for providing deb_pkg_tools, it's a library that we find immensely useful. :-)

That is always good to hear, I'm glad that you find it useful.

We'd be fairly happy to contribute a PR if you agree that these should be parsed. Thanks!

I never bothered adding Recommends and Suggests because I've never needed to use these fields, but I don't see any negative impact from adding these to DEPENDS_LIKE_FIELDS.

The Build-* fields were never added to DEPENDS_LIKE_FIELDS because my original use case(s) for deb-pkg-tools focused only on control fields commonly found in binary package archives, but again I don't see any problem with adding these.

Long story short: A pull request is definitely welcome, if not then I will likely pick this up myself soon (TM).

from python-deb-pkg-tools.

This was fixed with the release of deb-pkg-tools 4.1. Thanks again for the feedback!

from python-deb-pkg-tools.

Shortly after posting my previous message here, I realized that I never implemented a proper cache invalidation technique for the new package cache that was released in version 3.0 (which was added to support multiple simultaneous cache readers and writers without blocking). I was going to suggest:

Please make sure to wipe the cache if this has the potential to bite.

But on second thought, not implementing a cache invalidation technique is lame, so I added support for cache invalidation in release 4.2. This should ensure that cached package metadata is invalidated when it contains unparsed Suggests / Recommends/ etc. fields.

from python-deb-pkg-tools.