On Wed, Feb 01, 2012 at 06:01:25PM +0100, Raphael Hertzog wrote: > On Wed, 01 Feb 2012, Craig Sanders wrote: > > it makes perfect sense. a useful function provided by dpkg for the > > last 15+ years is being taken away. that's a bug. If dpkg can no > > longer provide access to the raw files (and I still don't have a clear > > understanding of why that's going to be the case, or why multiarch > > is inevitably going to cause that) then it should provide equivalent > > functionality. > > The existence of the .list file is not part of the public API of dpkg. > Thus you should not rely on it. > > The files will still be there but some of them will have different names > as I said (e.g. libc6:i386.list instead of libc6.list).
for the purposes of dlocate, should I actually care about that? I know I should do some research on this before commenting but based on what i've heard so far, it sounds to me as if by just continuing to do what I'm currently doing, that dlocate automatically becomes multiarch aware in that if both amd64 and i386 lib6 packages are installed then /var/lib/dlocate/dlocatedb will contain lines like: lib6:file1 lib6:file2 lib6:filen lib6:i386:file1 lib6:i386:file2 lib6:i386:filen or, as this could break other scripts that depend on dlocate's current output, i could do some trivial additional processing and have separate dlocatedb files for each architecture that has installed files. > > > So you can certainly concatenate the output of "dpkg -L <package>" > > > executed on all packages ? > > > > not exactly. the script that does the job uses perl readdir to loop > > through all the *.list files and (for each file) outputs each line > > prefixed by the package name and a ':'. > > 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). 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. > > I don't know for sure how long looping around 'dpkg -L' will take > > but it will be at least 25 minutes. on a fast system with an SSD. > > Wrong, we did the measurement already for popcon: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622322#105 > > So it's not 25 minutes but less than 10s if you batch 50 packages in > each call. > > This is surely acceptable for a nightly cron job. that sort of time is definitely acceptable - if i could trust the output. without batching, it really will take 25+ minutes. > > so there's the fix. if dpkg -L (or dpkg-query -L, or anything else) can > > provide that output format in a reasonable time (seconds rather than > > minutes or 10s of minutes) then the problem goes away. > > Deal. Reassigning back to dlocate. no, the problem isn't solved. you've just hand-waved it away. when listing multiple packages, dpkg -L should either prepend 'packagename:' to each line, or print the package name as the first line after the empty-line separator - making for easy and guaranteed-correct post-processing. that's the problem - i want dlocate's data to be provably correct, not just assumed correct. "works sometimes" is equivalent to "broken". craig -- craig sanders <[email protected]> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
