On Tue 28 Mar 2017 at 16:10:57 (+0000), Curt wrote: > On 2017-03-28, David Wright <deb...@lionunicorn.co.uk> wrote: > > On Sun 26 Mar 2017 at 11:31:57 (+0000), Curt wrote: > >> On 2017-03-25, David Wright <deb...@lionunicorn.co.uk> wrote: > >> > On Sat 25 Mar 2017 at 10:50:50 (+0000), Curt wrote: > >> >> Actually, srcpkgcache.bin includes the information contained in the > >> >> files > >> >> in /var/lib/apt/lists; that is, all the info you obtain from the > >> >> internet > >> >> via your deb and deb-src lines -- this information changes only on > >> >> apt-get update. > >> >> > >> >> pkgcache.bin caches the information in srcpkgcache.bin + the information > >> >> extracted from the apt and dpkg status files. This info changes on every > >> >> install/remove done by apt or directly by dpkg. > >> >> > > You can also see from the head of the file that the most of the > > "versions" are not the versions of the packages but are actually > > constraints, ie dependencies/replacements/breakages etc. all just > > jumbled up. > > Well, I actually checked further down than the head (let's refer to it > as the body) and I did systematically discover version and package > names, so I think the output is more coherent than you're letting on but > who cares? We know what is in those files (thank you David #1--yes I'm > relegating you to David #2, sorry). That is the point of my post in the > first place. It is not true what you posited, that it is tricky to know > what those files contain.
Well, I have _not_ looked further than the head, and I'm also unable to look at amd64 on wheezy, but i386 will do for my purpose. Here's your post again: curty@einstein:/var/cache/apt$ strings pkgcache.bin | less Standard .deb amd64 /var/lib/apt/lists/httpredir.debian.org_debian_dists_wheezy_main_binary-amd64_Packages httpredir.debian.org Debian Package Index 0~r11863-2 games 0ad-data 0~r11863 0~r11863-2 gamin libboost-signals1.49.0 1.49.0-1 libc6 2.11 libcurl3-gnutls <etc> and here's the i386 equivalent of where it originates: Package: 0ad Version: 0~r11863-2 Installed-Size: 7745 Maintainer: Debian Games Team <pkg-games-de...@lists.alioth.debian.org> Architecture: i386 Depends: 0ad-data (>= 0~r11863), 0ad-data (<= 0~r11863-2), gamin | fam, libboost-signals1.49.0 (>= 1.49.0-1), libc6 (>= 2.11), libcurl3-gnutls (>= 7.16.2), libenet1a, libgamin0 | libfam0, libgcc1 (>= 1:4.1.1), libgl1-mesa-glx | libgl1, libjpeg8 (>= 8c), libmozjs185-1.0 (>= 1.8.5-1.0.0+dfsg), libnvtt2, libopenal1, libpng12-0 (>= 1.2.13-4), libsdl1.2debian (>= 1.2.11), libstdc++6 (>= 4.6), libvorbisfile3 (>= 1.1.2), libwxbase2.8-0 (>= 2.8.12.1), libwxgtk2.8-0 (>= 2.8.12.1), libx11-6, libxcursor1 (>> 1.1.2), libxml2 (>= 2.7.4), zlib1g (>= 1:1.2.0) Pre-Depends: dpkg (>= 1.15.6~) Description: Real-time strategy game of ancient warfare Homepage: http://www.wildfiregames.com/0ad/ Description-md5: d943033bedada21853d2ae54a2578a7b Tag: game::strategy, implemented-in::c++, interface::x11, role::program, uitoolkit::sdl, uitoolkit::wxwidgets, use::gameplaying, x11::application Section: games Priority: optional Filename: pool/main/0/0ad/0ad_0~r11863-2_i386.deb Size: 2226038 MD5sum: 93699f007bcd8a51e1ab5fba2ecdc400 SHA1: 602e20176706d3cc7535f01ffdbe91b270ae5012 SHA256: 2b092f5682ae14351d6f7e47a7c113b7c0cc9ec71046a2e3ecf95eb453909ad8 Now you can see why these two lines appear in your post: libc6 2.11 but you won't find version 2.11 on you system (unless you're running aqueeze); you've got 2.13. So when you venture further into the body of your strings file, and you come across package-name version how are you going to know whether it's the version of a package, or just some casual mention under one of the other headings? You call that coherence? > We know (although it is not documented in the > man page(s) because people in the know figure these descriptions too > low-level for mortals like us. Maybe therein lies the trickiness. No, the trickiness is because it's binary: it's organised for the computer and disorganised for us humans. > > Within this jumble, I think it would be difficult to unambiguously > > locate information that was specific to apt-cdrom or synaptic, were > > either of these to add information not covered by your reference. > > > > $ ls -l /var/cache/apt/srcpkgcache.bin > > ... 22531192 Mar 27 21:00 /var/cache/apt/srcpkgcache.bin > > $ strings /var/cache/apt/srcpkgcache.bin | wc -c > > 3655511 > > $ > > so the output of strings amounts to about 16% which means that > > 84% could be "hiding" other information from our eyes. > > > > I've never looked at (let alone examined) these files after scanning > > CDs with synaptic (assuming these same filenames are used), so I have > > no idea whether they contain the same information as apt-get update > > writes, or more. And as for what man apt-cdrom means by > > "correcting for several possible mis-burns", I have no idea. > > They contain exactly what David #1 said they did, I assume, as I have no > good reason not to believe him (given that he's a bona fide authority on > the matter in his role as an APT contributor). My apologies for not searching the interweb and finding this before writing my post. But it still assumes that that's _all_ the file contains. The post doesn't talk about apt-cdrom's actions at all, let alone synaptic, and I haven't got either of those to run tests with. > But in the context of the OP why you couldn't copy the two files from > the first machine after the cds had been scanned and then copy them back > to the second machine in order to avoid rescanning I don't know. "To avoid rescanning" begs the question. The OP wants to know which other files are necessary to copy, and maintains that the ones in /var/lib/apt are not sufficient. Suckers like me are casting round for other possibilities. The last place I saw my Debian DVDs is already mentioned in the thread: "[they] could still be hanging from threads in the vegetable plot, scaring the birds." All I can do is make qualified suggestions for the OP to try out. Is that OK? Cheers, David.
