Your message dated Tue, 17 Aug 2010 17:43:16 +0100
with message-id <[email protected]>
and subject line Re: Bug#593329: Does the Wrong Thing when
target/var/cache/apt/archives is pre-populated
has caused the Debian Bug report #593329,
regarding archiving unpacking support query
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
593329: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593329
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: multistrap
Version: 2.1.6
Severity: minor
When repeatedly re-running multistrap, I wanted to avoid the lengthy
download time for the binary packages. So I did something like this:
- run multistrap with cleanup=false
- copy target/var/cache/apt/archives/*.deb to /var/cache/apt/archives/
Then, before each new multistrap run, I would
mkdir -p target/var/cache/apt/archives
cp -a /var/cache/apt/archives/*.deb target/var/cache/apt/archives/
I got a lot of confusing errors, until I realized that multistrap
basically iterates over ALL the packages in
target/var/cache/apt/archives/.
multistrap is assuming that the only files in the target's apt archive
are those *it* asked for via apt-get --download-only. This is not the
case in my pre-seeded cache scenario.
I suggest that you perform an apt-get --print-uris run prior the the
apt-get --download-only run, and use the resulting output to generate
the list of deb files to unpack.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.35 (SMP w/2 CPU cores)
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages multistrap depends on:
ii apt 0.7.25.3 Advanced front-end for dpkg
ii libconfig-auto-perl 0.20-2 Magical config file parser
ii libparse-debian-packages-perl 0.01-2 parse the data from a Debian Packa
ii perl 5.10.1-14 Larry Wall's Practical Extraction
ii realpath 1.15 Return the canonicalized absolute
Versions of packages multistrap recommends:
ii emdebian-archive-keyring 2.0.1 GnuPG archive keys for the emdebia
Versions of packages multistrap suggests:
ii fakeroot 1.14.4-1 Gives a fake root environment
-- no debconf information
--- End Message ---
--- Begin Message ---
notfound 593329 2.1.6
retitle 593329 archiving unpacking support query
quit
On Tue, 17 Aug 2010 19:35:35 +1000
"Trent W. Buck" <[email protected]> wrote:
> Package: multistrap
> Version: 2.1.6
> Severity: minor
>
> When repeatedly re-running multistrap, I wanted to avoid the lengthy
> download time for the binary packages.
The option to support this is to turn off cleanup mode, combined with
using copy:///directory/ as a multistrap source or some other, more
advanced, apt proxy/cache.
--tidy-up - remove apt cache data, downloaded Packages files and the
apt package cache. Same as cleanup=true.
Plus, multistrap is stateless and will use whatever packages already
exist. This is a feature of multistrap, not a bug.
> So I did something like this:
>
> - run multistrap with cleanup=false
> - copy target/var/cache/apt/archives/*.deb
> to /var/cache/apt/archives/
There is no point in doing this, cleanup=false is sufficient - you can
let the first run download the necessary packages, then use a proper apt
cache/proxy.
Your hack is nasty - if you want to do this properly, create a local
apt cache and pass that as the source for multistrap.
It is particularly bad to copy the archives to /var/cache/apt/ because
that is your system apt package cache!
> I got a lot of confusing errors, until I realized that multistrap
> basically iterates over ALL the packages in
> target/var/cache/apt/archives/.
Correct. This is intentional. This allows support for multiple runs in
a stateless manner (e.g. in case of network errors). It also expressly
allows for situations where archives may need to be manually added to
the install - although, as discussed below, there are better ways of
doing this which *also* fix your "problem" and render your hack moot.
> multistrap is assuming that the only files in the target's apt archive
> are those *it* asked for via apt-get --download-only.
It has every right to do so because it is stateless.
> This is not the
> case in my pre-seeded cache scenario.
... because your scenario is flawed and you should rethink how to do
what you seek to achieve.
> I suggest that you perform an apt-get --print-uris run prior the the
> apt-get --download-only run, and use the resulting output to generate
> the list of deb files to unpack.
I see no valid user case for such support - I certainly don't see a
need to support your hack. If you want to have an apt cache, set up an
apt cache.
You can do this without even having to create a dedicated repository or
rely on http:// - just leave the archives where they are (or in a
separate directory to which the archives are copied after the first
run) and pass that directory to multistrap as a copy:// source for
future runs.
See the "Section settings" description in the manpage.
Closing the bug report as the premise upon which the report is based is
itself flawed and the original scenario can already be handled properly
using existing support and tools.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
pgpm1AbtfVgsr.pgp
Description: PGP signature
--- End Message ---
