[Aptitude-devel] Bug#766122: thwarted due to missing partial/ directory that we aren't going to use anyway

積丹尼 Dan Jacobson jidanni at jidanni.org
Fri Feb 26 12:35:55 GMT 2016


MAFM> - hopefully just by remounting the USB partition as RW would have
MAFM> worked (provided that it has permissions/space to create an empty
MAFM> partial/ dir, which is only a few KB)

MAFM> - same case as above, but creating the partial/ by hand, and then the
MAFM> partition can be remounted RO again,

MAFM> - copying those ~100MB of files to /somewhere/writable/ and point the
MAFM> above variables to it instead of /mnt/usb/extra1

E.g., optical read-only media, also some RO directory on a LAN. And with
not enough local disk space to (wastefully need to) copy all the files
(4.7GB perhaps, just to mkdir an empty partial/) to somewhere writeable.

MAFM> In short, there are many possible solutions less dramatic than having
MAFM> to buy a new USB :-)

MAFM> Anyway, got a way around this, so marking as +pending.
>> 
>> Hope it involves a new variable.

MAFM> No, it involves not trying to download when there's no need to (which
MAFM> implies extra actions from libapt like "setting up the directories,
MAFM> create partial if missing, etc").

MAFM> I was doubting whether it was worthy of implement this extra check to
MAFM> not download, since I think that this is relatively obscure
MAFM> corner-case and easily solvable.  But then I thought that might be
MAFM> useful in the case of emergency recoveries with external media mounted
MAFM> as RO, it's a small micro-optimisation for aptitude in itself, etc.

Well I hope that will cover all the cases when a partial/ cannot be
created.

And... it wouldn't hurt to have an extra APT variable anyway in addition
to your solution ... e.g., the user is downloading and writing the
archives to some "write-once" (think CD-ROM) media, but wants any
temporary work done elsewhere...



More information about the Aptitude-devel mailing list