On Wed, Sep 19, 2012 at 01:40:39PM +0200, David Kalnischkies wrote: >On Mon, Sep 17, 2012 at 4:37 PM, Steve McIntyre <st...@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.
Hmmm. Could we stick with the same format as in Packages instead, please? It's much less open to confusion that way... :-/ Other people will end up reading logs from debian-cd, for example. >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). Cool. >(This bug will NOT be closed by this as it is neither the default nor > documented or has a 'proper' flag etc etc pp) ACK. >>>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. Yep, that's something we'll have to accommodate at some point soon. >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 … That makes sense, yes :-) -- Steve McIntyre, Cambridge, UK. st...@einval.com You lock the door And throw away the key There's someone in my head but it's not me -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org