When doing apt-get download -o RootDir=. apt
once it's downloaded the package it effectively tries to move it to
./$( pwd )/

(the prefix is whatever RootDir points to) instead of moving to
$( pwd )/

This causes it to fail unless you do a
mkdir -p ./$( readlink -f $( pwd ) )

Is this a bug or a feature?

You also can get weird errors about cannot rename across filesystems
where RootDir is not on the same filesystem as $(pwd)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Oct 30, 2021 at 10:14:15AM +0100, Tim Woodall wrote:

When doing apt-get download -o RootDir=. apt
once it's downloaded the package it effectively tries to move it to
./$( pwd )/

(the prefix is whatever RootDir points to) instead of moving to
$( pwd )/

This causes it to fail unless you do a
mkdir -p ./$( readlink -f $( pwd ) )

Is this a bug or a feature?

Working as intended. 'download' wants to store the package in the
current directory, so it gets the absolute path name to that as "current directory" isn't a very stable property.

With RootDir (as the manpage explains) you say: Whatever the path, stick
this in front of it – so you get what you asked for…
RootDir has some uses if you deal with chroots from the outside, but
fiddling even with absolute paths is usually not what you want – the
manpage mentions Dir which effects only "relative" paths (most paths in
apt like where it finds its config files are relative to Dir – which by default is '/' making it an absolute path in the process).

As you fiddle with directories you are likely to need APT_CONFIG as that
is parsed before the configuration files (and so can effect where those
are) and long before the command line is looked at (all at length
explained in the apt.conf manpage).


There is no option to set 'download's target directory from current
directory to another place at the moment. Shouldn't be incredibly hard
to implement if someone wanted to try (apt-private/private-download.cc
→ DoDownload() → implement an option who sets Dir::Cache::Archives to something else than the absolute CWD – absolute? I already mentioned
what would happen otherwise, so connecting the dots is left as an
exercise for the reader).


So, what are you actually trying to do?


And next time, try to pick a slightly more sensible title and perhaps
even a more fitting place to ask first… I am ever so slightly annoyed
if I am kicked into high gear expecting a world ending disaster as it
escalated to an apt-thread on debian-devel…
(so now, where were I before this 'emergency call' came in… mhhh)


Best regards

David Kalnischkies

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmF9IFMACgkQMRvlz3HQ eIMVOQ/+LnlrJyia5XT7WVtxbp7IYJR6N2dRsMYJUUFVb3WPngBBvG2SsWPyoQ/e yeG8MfZHHrK6j0ns4f9cGSKHcj3c7iF+eax4A9b7NTaImDFAiPZ5AwEQePr1ZtPA pMdPTdAa7Snc7OLj0YQPC37sPRdsrMRZGlSlfgo+mapatDRSiRKtONz+FsjhsUdV ZMC1KYzZ5hCTzXFpaTyZ7KpFBl4ME3XC0b7d8sWyPVG675iBwWpSZ5/mqrh3ZyRg W31t66EDTNj9ZUu8S+FNtBBwcIpTgQ4yDjdrRt6lkTXH4WCK6Q80TU+ftWxuAdSP OPyoWTNEL9o/7kke7HHLMml0P9QZD1qzXtvAagsuVDKbJcRyGo5EN+x4AQ5YVX0G j3YmnIZC1vG1jxFyApj0kgq/9DdxMM3jpUfDr7+Wq+OBPd+VIGKEzjkJuMTTXz4O tfVGuRbAGA6qxg8Esv6+XPxvw3FVyqh+Y0NZVwS4O8M9niKR1hAig0unGdQph5vw CgV4bv9DbKjPxyBaP38kJ3a/nC2/RPxP9a9yhq/Vg6ijtU5Ls+S2C1NTuxmSQWyQ Le9yI9Ghgc2h3J+PCUFnuCZAv7FHfySbA+ktQtav+y3Tl/NaLkXptVQMFGrAHhAK 1zDln0vABXa5yFJyv4Ioah427188K87CSHSTabEDZ6BTh7OgzZM=
=X1WD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 30 Oct 2021, David Kalnischkies wrote:

On Sat, Oct 30, 2021 at 10:14:15AM +0100, Tim Woodall wrote:

When doing apt-get download -o RootDir=. apt
once it's downloaded the package it effectively tries to move it to
./$( pwd )/

(the prefix is whatever RootDir points to) instead of moving to
$( pwd )/

This causes it to fail unless you do a
mkdir -p ./$( readlink -f $( pwd ) )

Is this a bug or a feature?

Working as intended. 'download' wants to store the package in the
current directory, so it gets the absolute path name to that as "current directory" isn't a very stable property.

With RootDir (as the manpage explains) you say: Whatever the path, stick
this in front of it ? so you get what you asked for?
RootDir has some uses if you deal with chroots from the outside, but
fiddling even with absolute paths is usually not what you want ? the
manpage mentions Dir which effects only "relative" paths (most paths in
apt like where it finds its config files are relative to Dir ? which by default is '/' making it an absolute path in the process).

As you fiddle with directories you are likely to need APT_CONFIG as that
is parsed before the configuration files (and so can effect where those
are) and long before the command line is looked at (all at length
explained in the apt.conf manpage).

There is no option to set 'download's target directory from current
directory to another place at the moment. Shouldn't be incredibly hard
to implement if someone wanted to try (apt-private/private-download.cc
? DoDownload() ? implement an option who sets Dir::Cache::Archives to something else than the absolute CWD ? absolute? I already mentioned
what would happen otherwise, so connecting the dots is left as an
exercise for the reader).

So, what are you actually trying to do?

And next time, try to pick a slightly more sensible title and perhaps
even a more fitting place to ask first? I am ever so slightly annoyed
if I am kicked into high gear expecting a world ending disaster as it escalated to an apt-thread on debian-devel?
(so now, where were I before this 'emergency call' came in? mhhh)

Apologies. I thought "apt annoyance" was a fitting title as that is all
it is, an annoyance. I can, and have, worked around the "must be same filesystem" by doing a cd into RootDir.

It wasn't at all obvious to me that "current directory" isn't still
the current directory when RootDir is set. And the fact that apt fails
to create the target directory if it doesn't exist and also doesn't work
if $PWD and <rootdir>/$PWD are on different filesystems even if they do
both exit made me wonder if this was deliberate (but annoying to me) or
an oversight - in which case I'd have taken a look as to whether I could provide a patch to always download to the current directory.

What I found really weird was that it actually successfully downloaded
it into the current directory, then tried to rename it to the directory prefixed by RootDir, which failed because it was a different filesystem
(even though I'd created the directory) and I don't want to ignore the
failure exitcode from apt-get in case something unexpected goes wrong.

What I'm doing is downloading (and patching) certain packages across architectures and releases to build a minimal chroot that I can then use
under lxc to bootstrap an entire system and/or to rebuild certain
packages with different configuration to the debian default across architectures without having to have a separate build system for each architecture.

I know there are other ways of doing this - but at the time I started on
this route the only tool I knew of was debootstrap and that had problems
with combining cross-architecture, fakeroot and minbase.

I bootstrap exclusively using apt and dpkg, with a few minor tweaks so
that apt can reliably generate a successful install plan when installing
the initial essential packages after dpkg has unpacked them.

Apologies again!

Tim.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 2021-10-30 at 12:52 +0100, Tim Woodall wrote:

I bootstrap exclusively using apt and dpkg, with a few minor tweaks so
that apt can reliably generate a successful install plan when installing
the initial essential packages after dpkg has unpacked them.

Sounds like you should take a look at mmdebstrap.

--
bye,
pabs

https://wiki.debian.org/PaulWise

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYQsotVz8/kXqG1Y7MRa6Xp/6aaMFAmF94ZIACgkQMRa6Xp/6 aaPoThAAlrnGQLtuBNmhm93GaVlj9OY4ekrnEbL21uB0Kooj3J3Gu6QSRIL3qfYj jD8spnW50ec3alIZOqYiW9xEJ4kdW6YhLtUDDi368A5earZl3MfU7KhFBiHBtL8S +a+IxBSeKghQiEzGBgupx4peuHRK9OX7dAJunNAV0iAibASnPcv/tV2LJYNcm48G cR5vJWzQI53vyyXSCQAYPThaFmJ57JDBum/T4NRq9Q2xy0d+exlooo0CUYVziuoF 5syjGFVQVvcmvYVc/KPYllekq38IZTCmqaG1pZFyIqf4Xry7lVJvEtic524QNU95 z7sN9bIGZWy9Pk3y/fOze2IyBBx1YwfPZb5DUYnzzpTmS/O2GpZ6C/pt/MYXACB/ zekTCZG4cjm+7zM3tHNyO8UGhPWpVz7dbXYLYKUsNii5fggLMXcfDVAeZmUvhpr1 oLJyU1B5sRprKhquzLo9HG3vUkQn9aglQzI2HD4uZESCpeIAs20Od5zOukRWPS2/ 1xFme4cbVKgdjxRZixTUBYo9fPSqhGqJ43e4WGPY/ttTxzyxftav+H9vFvgloahe 4EDuSyFleV5YBw9s7xf8IS9KweiETqqKLwWz9DR5752pEkoznvADThM65ok7z230 yjVEmLy2lUOg4f2NkOuzsiMhFhqzvIfMuby05td61COjNzQUYkA=
=IyDa
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)