Control: tags -1 moreinfo
On Sun, 2016-09-25 at 16:46:56 -0700, Elliott Mitchell wrote:
> Package: dpkg
> Version: 1.17.27
> When installing packages which *only* have files in /usr, I generally
> try to leave / read-only. With the recent release of `dpkg` though this
> has become problematic.
Do you mean that it used to work, and it does not anymore. In which
case, what versions?
> >From the error message, during unpacking `dpkg` is trying to create a
> file/directory as /usr.dpkg-tmp, which fails if / is read-only. This
> could actually cause some problems. Notably if `dpkg` is doing this to
> check whether the filesystem has sufficient free space, this check *WILL*
> fail since / and /usr could well be different filesystems. This could
> also cause trouble if /usr.dpkg-tmp is large and / has limited free
> space.
This should not happen for pre-existing directories, and dpkg should
skip those. The actual error message would be helpful here. Also the
debug output from using -D113 would also be helpful.
> I'm unsure how to rate the severity of this issue. This is distinctly
> annoying and can trigger warning flags, but I suppose in many cases it
> won't cause problems for people. Folks who always remount / read-write
> when upgrading packages may well not notice, but those of use who pay a
> bit more attention do notice.
I'm actually very surprised by this bug report, because something
related was fixed in dpkg 1.17.14, so the version you are reporting
against should actually behave better for your use case:
* Never try to remove the root directory or its backups. There's no point in
it, and makes life more difficult for a read-only root with a read-write
overlay or a symlink farm. Requested by sepero...@gmx.com.
Thanks,
Guillem
