Bug#218995: Patch for #218995
On Wed, Sep 19, 2012 at 1:55 PM, Steve McIntyre st...@einval.com wrote: 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. Short version: Mhh. Okay - just for you now in wheezy. ;) For Jessie we will drop this difference for everyone. Updated patch attached. Novella version: '' and '' in Debian are long obsolete and dpkg-gencontrol and lintian warn (obsolete-relation-form-in-source) about their usage, so I guess it is more confusing for tools than for people (as the later will forget the minor detail they have read in the policy, tools usually don't forget that easily). Anyway, I walked through history a bit in a try to figure out why APT tries to establish it's own style here and it seems to originate from the good old times of lets replace dpkg and lets work with 'aliens', too. (alien seems to be rpm, but it is never mentioned explicitly and while an old apt-rpm fork exists which uses these abstraction levels it never caused support for alien to ever land in mainline so far…) Walking a bit through code tells me that this is actually the first time we use it in output which can be used by others. The old uses are only in debug code and in the broken dependency list message which is far from being parser friendly anyway. A quick grep in aptitude suggests similar usage patterns. And somehow I doubt that this style has that many users (if at all) out there given that it is not documented and far to similar to the usual debian-style you would usually expect to see here … Combining the two threads suggests that this is a perfect opportunity to change behavior here by dropping APT-style for Jessie before providing officially a command which will not allow us to do that in the future. And as I can't time-travel we will fake it (for apt-cache depends) until we make it (for all in DepIterator::CompType() ). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
On Wed, Sep 26, 2012 at 03:50:52PM +0200, David Kalnischkies wrote: On Wed, Sep 19, 2012 at 1:55 PM, Steve McIntyre st...@einval.com wrote: On Wed, Sep 19, 2012 at 01:40:39PM +0200, David Kalnischkies wrote: 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. Short version: Mhh. Okay - just for you now in wheezy. ;) For Jessie we will drop this difference for everyone. Updated patch attached. U - where? :-) Novella version: '' and '' in Debian are long obsolete and dpkg-gencontrol and lintian warn (obsolete-relation-form-in-source) about their usage, so I guess it is more confusing for tools than for people (as the later will forget the minor detail they have read in the policy, tools usually don't forget that easily). Anyway, I walked through history a bit in a try to figure out why APT tries to establish it's own style here and it seems to originate from the good old times of lets replace dpkg and lets work with 'aliens', too. (alien seems to be rpm, but it is never mentioned explicitly and while an old apt-rpm fork exists which uses these abstraction levels it never caused support for alien to ever land in mainline so far…) Right. Walking a bit through code tells me that this is actually the first time we use it in output which can be used by others. The old uses are only in debug code and in the broken dependency list message which is far from being parser friendly anyway. A quick grep in aptitude suggests similar usage patterns. And somehow I doubt that this style has that many users (if at all) out there given that it is not documented and far to similar to the usual debian-style you would usually expect to see here … Combining the two threads suggests that this is a perfect opportunity to change behavior here by dropping APT-style for Jessie before providing officially a command which will not allow us to do that in the future. And as I can't time-travel we will fake it (for apt-cache depends) until we make it (for all in DepIterator::CompType() ). OK, cool. I'll update the debian-cd code to use the new output style as soon as I see the patch... :-) -- Steve McIntyre, Cambridge, UK.st...@einval.com Managing a volunteer open source project is a lot like herding kittens, except the kittens randomly appear and disappear because they have day jobs. -- Matt Mackall -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
On 26 September 2012 21:50, David Kalnischkies kalnischkies+deb...@gmail.com wrote: Combining the two threads suggests that this is a perfect opportunity to change behavior here by dropping APT-style for Jessie before providing officially a command which will not allow us to do that in the future. And as I can't time-travel we will fake it (for apt-cache depends) until we make it (for all in DepIterator::CompType() ). [Erases plan to push for utf8 output from CompType (natural operators, like “≤”) where supported by the locale.] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
On 26 September 2012 22:49, Daniel Hartwig mand...@gmail.com wrote: On 26 September 2012 21:50, David Kalnischkies kalnischkies+deb...@gmail.com wrote: Combining the two threads suggests that this is a perfect opportunity to change behavior here by dropping APT-style for Jessie before providing officially a command which will not allow us to do that in the future. And as I can't time-travel we will fake it (for apt-cache depends) until we make it (for all in DepIterator::CompType() ). [Erases plan to push for utf8 output from CompType (natural operators, like “≤”) where supported by the locale.] … because it seemed to me that the distinction is that CompType is a natural representation, and CompTypeDeb is for machine parsing. ? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
Updated patch attached. U - where? :-) Huh. I created a diff in my /tmp, I thought this would be enough. Silly me … Attached now I hope, but the diff-diff is really not that big. On Wed, Sep 26, 2012 at 4:51 PM, Daniel Hartwig mand...@gmail.com wrote: On 26 September 2012 22:49, Daniel Hartwig mand...@gmail.com wrote: On 26 September 2012 21:50, David Kalnischkies kalnischkies+deb...@gmail.com wrote: Combining the two threads suggests that this is a perfect opportunity to change behavior here by dropping APT-style for Jessie before providing officially a command which will not allow us to do that in the future. And as I can't time-travel we will fake it (for apt-cache depends) until we make it (for all in DepIterator::CompType() ). [Erases plan to push for utf8 output from CompType (natural operators, like “≤”) where supported by the locale.] … because it seemed to me that the distinction is that CompType is a natural representation, and CompTypeDeb is for machine parsing. ? Kinda, but I think the not-availability of CompTypeDeb from DepIterator makes the behavior of CompType unexpected. I might be biased here, but I made this mistake myself at least once while working on EDSP. Suddenly returning UTF-8 characters in a char* will be even more unexpected. So while I think a pretty-print function might be nice, it shouldn't be (the default mode of) CompType(). Beside that I am not sure if the operator ≤ is better than = for users in a console application like apt-get -- but maybe in T- and GUIs. Anyway, I think this is the topic of a different discussion after wheezy. Best regards David Kalnischkies apt-218995-apt-cache-depends-show-version-v2.diff Description: Binary data
Bug#218995: Patch for #218995
On Wed, Sep 26, 2012 at 06:58:26PM +0200, David Kalnischkies wrote: Updated patch attached. U - where? :-) Huh. I created a diff in my /tmp, I thought this would be enough. Silly me … Attached now I hope, but the diff-diff is really not that big. Lovely, thanks. I've tweaked my debian-cd code to use this now, and all works perfectly. Please go ahead and get this change in for wheezy! -- 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
Bug#218995: Patch for #218995
On 27 September 2012 00:58, David Kalnischkies kalnischkies+deb...@gmail.com wrote: … because it seemed to me that the distinction is that CompType is a natural representation, and CompTypeDeb is for machine parsing. ? Kinda, but I think the not-availability of CompTypeDeb from DepIterator makes the behavior of CompType unexpected. I might be biased here, but I made this mistake myself at least once while working on EDSP. True. Though DepIterator does not provide a deb-compatible/machine-parsable DepType. Suddenly returning UTF-8 characters in a char* will be even more unexpected. So while I think a pretty-print function might be nice, it shouldn't be (the default mode of) CompType(). Perhaps, though we already expect locale-specific strings from it's peers DepType and Priority. Beside that I am not sure if the operator ≤ is better than = for users in a console application like apt-get -- but maybe in T- and GUIs. Anyway, I think this is the topic of a different discussion after wheezy. Yes, why I haven't mentioned it before. I will probably persue this later :-) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
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. 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 apt-218995-apt-cache-depends-show-version.diff Description: Binary data
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 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
Bug#218995: Patch for #218995
block 687949 by 218995 severity 218995 important thanks On Sun, Sep 09, 2012 at 01:06:08PM -0400, Sam Lidder wrote: I've attached a patch which appends package version information to the package names for apt-cache depends and rdepends. The patch is also available here: https://code.launchpad.net/~sam-lidder/apt/debian-experimental (revision 2249) Notes: - version information is not displayed for virtual/non-real packages - version is always printed, even if CompareOp is 0, so as to be consistent with output of 'Dependencies' for 'apt-cache showpkg pkg' Hi Sam, Awesome - I was just about to start hacking on the apt-cache code to do this and found you'd beaten me to it! :-) Apt maintainers - I need this fixed to allow me to fix #687949 in debian-cd, which is a serious bug affecting wheezy builds right now. Could you please prepare a build for upload with this patch added? If there's a worry about maybe breaking other users, maybe keep existing behaviour by default and add a -v or --with-versions flag to get the versions included? -- Steve McIntyre, Cambridge, UK.st...@einval.com I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
On 17 September 2012 20:38, Steve McIntyre st...@einval.com wrote: Notes: - version information is not displayed for virtual/non-real packages - version is always printed, even if CompareOp is 0, so as to be consistent with output of 'Dependencies' for 'apt-cache showpkg pkg' Hi Sam, Awesome - I was just about to start hacking on the apt-cache code to do this and found you'd beaten me to it! :-) Apt maintainers - I need this fixed to allow me to fix #687949 in debian-cd, which is a serious bug affecting wheezy builds right now. Could you please prepare a build for upload with this patch added? If there's a worry about maybe breaking other users, maybe keep existing behaviour by default and add a -v or --with-versions flag to get the versions included? Can't you get the required information already from show and showpkg? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
Hi Daniel, On Mon, Sep 17, 2012 at 08:58:33PM +0800, Daniel Hartwig wrote: On 17 September 2012 20:38, Steve McIntyre st...@einval.com wrote: Notes: - version information is not displayed for virtual/non-real packages - version is always printed, even if CompareOp is 0, so as to be consistent with output of 'Dependencies' for 'apt-cache showpkg pkg' Hi Sam, Awesome - I was just about to start hacking on the apt-cache code to do this and found you'd beaten me to it! :-) Apt maintainers - I need this fixed to allow me to fix #687949 in debian-cd, which is a serious bug affecting wheezy builds right now. Could you please prepare a build for upload with this patch added? If there's a worry about maybe breaking other users, maybe keep existing behaviour by default and add a -v or --with-versions flag to get the versions included? Can't you get the required information already from show and showpkg? It's possible, but substantially harder to parse reliably. This is the whole point of depends AFAICS... -- Steve McIntyre, Cambridge, UK.st...@einval.com Who needs computer imagery when you've got Brian Blessed? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
On 17 September 2012 21:03, Steve McIntyre st...@einval.com wrote: Can't you get the required information already from show and showpkg? It's possible, but substantially harder to parse reliably. This is the whole point of depends AFAICS... Ok. Still, “apt-cache show” output is direct from Packages so no chance of funny business. Anyway, I see that changing to use show is more work, since your tools/sort_deps is already quite cosy with depends :-) Regards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
On Mon, Sep 17, 2012 at 2:38 PM, Steve McIntyre st...@einval.com wrote: On Sun, Sep 09, 2012 at 01:06:08PM -0400, Sam Lidder wrote: I've attached a patch which appends package version information to the package names for apt-cache depends and rdepends. The patch is also available here: https://code.launchpad.net/~sam-lidder/apt/debian-experimental (revision 2249) Notes: - version information is not displayed for virtual/non-real packages - version is always printed, even if CompareOp is 0, so as to be consistent with output of 'Dependencies' for 'apt-cache showpkg pkg' Hi Sam, Awesome - I was just about to start hacking on the apt-cache code to do this and found you'd beaten me to it! :-) Truth to be told: He did it even earlier as part of his GSoC proposal. Apt maintainers - I need this fixed to allow me to fix #687949 in debian-cd, which is a serious bug affecting wheezy builds right now. Could you please prepare a build for upload with this patch added? If there's a worry about maybe breaking other users, maybe keep existing behaviour by default and add a -v or --with-versions flag to get the versions included? It is indeed a worry about breaking users. There is so much stuff outwhere using apt-* in strange ways that nearly every change to the output usually results in breaking at least one of them. I e.g. didn't know that debian-cd scripts are using it … 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. If you need it we can add it with -o APT::Cache::ShowVersion=1 as Depends: awesome Depends: stuff ( 2-1) I guess. -v is taken by --version; -V would be an option and very similar to apt-get -V (--verbose-versions), but i don't think this needs to consume a short flag which might be better used for activating a generally improved version of the (r)depends commands (e.g. to enable showing the dependency types in rdepends by default, too) with the necessary documentation … but that is a bit much while in freeze. -o flags on the other hand are cheap to add … 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 …). Best regards David Kalnischkies -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
On Mon, Sep 17, 2012 at 03:58:00PM +0200, David Kalnischkies wrote: On Mon, Sep 17, 2012 at 2:38 PM, Steve McIntyre st...@einval.com wrote: On Sun, Sep 09, 2012 at 01:06:08PM -0400, Sam Lidder wrote: I've attached a patch which appends package version information to the package names for apt-cache depends and rdepends. The patch is also available here: https://code.launchpad.net/~sam-lidder/apt/debian-experimental (revision 2249) Notes: - version information is not displayed for virtual/non-real packages - version is always printed, even if CompareOp is 0, so as to be consistent with output of 'Dependencies' for 'apt-cache showpkg pkg' Hi Sam, Awesome - I was just about to start hacking on the apt-cache code to do this and found you'd beaten me to it! :-) Truth to be told: He did it even earlier as part of his GSoC proposal. Ah, OK... :-) Apt maintainers - I need this fixed to allow me to fix #687949 in debian-cd, which is a serious bug affecting wheezy builds right now. Could you please prepare a build for upload with this patch added? If there's a worry about maybe breaking other users, maybe keep existing behaviour by default and add a -v or --with-versions flag to get the versions included? It is indeed a worry about breaking users. There is so much stuff outwhere using apt-* in strange ways that nearly every change to the output usually results in breaking at least one of them. I e.g. didn't know that debian-cd scripts are using it … To be honest, I only worked this out while tracking down this bug - this deep section of the code seems to have been working fine ever since Raphael wrote it ~10 years ago! :-) 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. If you need it we can add it with -o APT::Cache::ShowVersion=1 as Depends: awesome Depends: stuff ( 2-1) I guess. -v is taken by --version; -V would be an option and very similar to apt-get -V (--verbose-versions), but i don't think this needs to consume a short flag which might be better used for activating a generally improved version of the (r)depends commands (e.g. to enable showing the dependency types in rdepends by default, too) with the necessary documentation … but that is a bit much while in freeze. -o flags on the other hand are cheap to add … Sure, that all makes sense to me. I'll need to use a locally-built apt-cache for now (as we build using squeeze), until we upgrade the build machine after the wheezy release. I've designed around coping with versions not being available - it will just fall back to the old behaviour anyway. Is apt happy to ignore -o flags it doesn't recognise, or will I have to add some detection here to cope with older versions? 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! Thanks for the very quick response, it's appreciated. -- Steve McIntyre, Cambridge, UK.st...@einval.com The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. -- James D. Nicoll -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
On 17 September 2012 22:37, Steve McIntyre st...@einval.com wrote: 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. There is also libdpkg-perl with Dpkg::Deps deps_parse that will parse the “Depends: foo | bar, baz (...” lines from Packages/apt-cache show. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
On Mon, Sep 17, 2012 at 10:49:06PM +0800, Daniel Hartwig wrote: On 17 September 2012 22:37, Steve McIntyre st...@einval.com wrote: 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. There is also libdpkg-perl with Dpkg::Deps deps_parse that will parse the “Depends: foo | bar, baz (...” lines from Packages/apt-cache show. Yup. I know. I'm going to end up using some of the Dpkg::Deps code to at least allow me to do sensible version comparisons, but the rest of the code is probably less useful in this case. Rather than dig through things like virtual depends, it's much easier to just let apt tell me about them... -- Steve McIntyre, Cambridge, UK.st...@einval.com Since phone messaging became popular, the young generation has lost the ability to read or write anything that is longer than one hundred and sixty characters. -- Ignatios Souvatzis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#218995: Patch for #218995
I've attached a patch which appends package version information to the package names for apt-cache depends and rdepends. The patch is also available here: https://code.launchpad.net/~sam-lidder/apt/debian-experimental (revision 2249) Notes: - version information is not displayed for virtual/non-real packages - version is always printed, even if CompareOp is 0, so as to be consistent with output of 'Dependencies' for 'apt-cache showpkg pkg' 218995.patch Description: Binary data
