On Wed, Feb 01, 2012 at 10:59:49PM +0100, Raphael Hertzog wrote: > On Thu, 02 Feb 2012, Craig Sanders wrote: > > > The various sets of files are separated by an empty line, so you can > > > still map each file to the corresponding package. > > > > to paraphrase - the order of output of package file lists is not > > documented or guaranteed thus i should not rely on it. > > > > I did look at the dpkg -L output files, so it had occurred to me that > > doing what you suggest was an obvious possibility, but it also occurred > > to me that it was a stupid assumption to make. while it seems to be > > dpkg's behaviour right now, there's no guarantee that in some future > > optimisation the package list won't be sorted or stored in an internal > > hash of some kind (and thus become unordered). > > It's not a stupid assumption... otherwise we would not have documented > the fact that you can query multiple packages at once.
actually, it is a stupid assumption because all assumptions are stupid. documenting the fact that dpkg -L can query multiple packages at once is *NOT* the same as documenting the order of the output. > The package names are stored in the argument list (argv[]) and this one > will not be reordered magically... there's no intermediate storage of any > kind (and there's no need for it). > > Please trust the dpkg maintainers when it comes to dpkg's interface. I'm > ccing Guillem just in case he disagrees on this, but I doubt it. He's the > one who committed the earlier clarification already. good. your informal speculations and assertions in a bug report don't constitute actual documentation, though. > > so, in effect, you're telling me to switch from undocumented but clearly > > correct behaviour (libc6.list contains a list of libc6's files, not > > those of some other package) to undocumented and assumed behaviour. > > It's not really undocumented: > > -L, --listfiles package-name... > List files installed to your system from package-name. When multiple > pack‐ > age-name are listed, the requested lists of files are separated by > an empty > line. However, note that files created by package-specific > installation- > scripts are not listed. that documents dpkg -L's capability of listing multiple packages. it says *nothing* about the order of output. > I fail to see how one could understand that dpkg would reorder the > list of packages it has been asked to process. I never said that it *would* re-order the list. I pointed out that there is no documentation stating that it won't, or that some future dpkg update wont. that's why it's an assumption. > But feel free to suggest a wording that fixes your fears and I'll > commit it so that you can feel confident in using it. firstly, the documentation fix is obvious. secondly, this goes beyond a documentation issue. You're modifying dpkg to take away useful information that's been available for over 15 years, but you're refusing to provide equivalent functionality - what's so difficult about adding an option for dpkg to produce the output format requested (i notice that the popcon bug report you mentioned also made a very similar request)? thirdly, you didn't answer my question about whether I should actually care about the upcoming multiarch changes in the context of dlocate. for dlocate's purposes, the architecture of a file is irrelevant. all that matters is what package it belongs to. At this stage, I don't even see that there's even a real problem or bug, let alone one of Important severity. craig -- craig sanders <c...@taz.net.au> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
