Re: An INCOMPLETE solution - was [Re: Where is data stored when Synaptic scans DVDs?]
On Tue 28 Mar 2017 at 16:10:57 (+0000), Curt wrote:
> On 2017-03-28, David Wright <deblis@lionunicorn.co.uk> wrote:
> > On Sun 26 Mar 2017 at 11:31:57 (+0000), Curt wrote:
> >> On 2017-03-25, David Wright <deblis@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-devel@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.
Reply to: