Bug#218995: Patch for #218995
On Wed, Sep 19, 2012 at 01:40:39PM +0200, David Kalnischkies wrote:
>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.
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. steve@einval.com
You lock the door
And throw away the key
There's someone in my head but it's not me
Reply to: