On Mon, Sep 17, 2012 at 4:37 PM, Steve McIntyre <steve@einval.com> wrote: > On Mon, Sep 17, 2012 at 03:58:00PM +0200, David Kalnischkies wrote: >>The other thing is that the generated output is less than stellar. >>I think if we output something here it should be in the way we see >>it in the Packages file and not intermixed some internal values … >>Depends: awesome (0 (null)) >>Depends: stuff (3 2-1) >>Nobody knows what 0 and 3 are and they could possibly change any >>given minute (with an ABI break of course) -- beside that this number >>printed includes also other stuff (like the OR flag) and showpkg is kind >>of a debug command, so "compatibility" with it isn't really needed. > > ACK. I was a little surprised to see the output format here. I've > added support for parsing the versions in apt's internal format, by > digging through source code to find the definitions. I can always > switch that code back to parsing human-readable text, thought. I think we will go with the attached patch, which prints a human-readable nearly debian-style compare operator. I say nearly as I want to highlight that - as is in other code paths - the dependency found in Packages: Depends: awesome (<< 2-1) | awesome (>> 3-1) will be printed as: Depends: awesome (< 2-1) | awesome (> 3-1) This is an interpretation difference, as older debian policies (now in §4.9.4 we reached the stage of denial: You must not use them) allowed the usage of '<' with the meaning of '<='. So be careful while parsing it that the right interpretation is used. The rest are one on one mappings. You can activate it with apt-cache depends -o APT::Cache::ShowVersion=1 The -o flag can be placed anywhere in the call and will be ignored by versions not supporting this option. Support should be there in the next bugfix accumulation upload (named 0.9.7.6). (This bug will NOT be closed by this as it is neither the default nor documented or has a 'proper' flag etc etc pp) >>Anyway, as this will be advertised as a debian-cd fix implemented in APT >>to the release team, feel free to define the output you need and we will >>see how to generate it. I am unable to read/write perl, so I don't know what >>is easiest. (I can see in the code though that you should have a look at >> --important, --no-recommends and similar flags to avoid doing the filtering >> in perl; but I don't get what the code does in general …). > > That's fine. :-) Just adding versions in a sane manner (as you've > suggested here) is great for me. Maybe post-wheezy I'll get on to > investigating other changes for the sort_deps code, but right now is > not a good time for major surgery! I thought so. :) Just wanted to highlight this for future changes. Another which might or might not be noteworthy as I don't know if we have to worry at that stage about MultiArch (maybe with multi-arch cds?): In multi-arch environments (and later with architecture-specific dependencies) you will encounter "Depends: package:arch" lines. And the implicit dependencies for multi-arch will be explicitly listed. I still wonder what sort_deps actually does though, maybe we can trick APT into generating what you need for jessie. Installation order is a field we have an enormous amount of code for which at its heart sorts dependencies after all … Best regards David Kalnischkies
Attachment:
apt-218995-apt-cache-depends-show-version.diff
Description: Binary data