[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: users not reading manpages annoyance [was: apt annoyance]

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.
Reply to: