Your message dated Thu, 11 Jun 2015 11:25:01 +0200
with message-id <[email protected]>
and subject line Re: Bug#788417: dpkg-statoverride --update logic flawed
has caused the Debian Bug report #788417,
regarding dpkg-statoverride --update logic flawed
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.)
--
788417: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=788417
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: dpkg
Version: 1.17.5ubuntu5.4
Severity: normal
Dear Maintainer,
On my Ubuntu system I get kernel update failures because of some existing
dpkg-statoverride rules. This led me to investigate how dpkg-statoverride
works, and I discovered that there's an --update option that according to how I
understand the man page ought to make it possible to update an existing
override. But the option was already present in
/etc/kernel/postinst.d/statoverride. That led me to look at the code.
So the issue is that in src/statcmd.c:statoverride_add the logic seems flawed
in the sense that it first checks that the file exists -- and errors out if it
does -- then, if --update is specified, it checks again, and warns if it
*doesn't* exist, but at this point it cannot exist, at least not unless --force
is also specified.
My assumption would be that it should not be an error that the file exists when
specifying --update.
It seems to be identical in the git master branch as in my Ubuntu version.
-- System Information:
Debian Release: jessie/sid
APT prefers trusty-updates
APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 'trusty')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.13.0-53-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages dpkg depends on:
ii libbz2-1.0 1.0.6-5
ii libc6 2.19-0ubuntu6.6
ii liblzma5 5.1.1alpha+20120614-2ubuntu2
ii libselinux1 2.2.2-1ubuntu0.1
ii tar 1.27.1-1
ii zlib1g 1:1.2.8.dfsg-1ubuntu1
dpkg recommends no packages.
Versions of packages dpkg suggests:
ii apt 1.0.1ubuntu2.8
-- no debconf information
--- End Message ---
--- Begin Message ---
Hi!
On Thu, 2015-06-11 at 09:48:14 +0200, Stian Sletner wrote:
> Package: dpkg
> Version: 1.17.5ubuntu5.4
> Severity: normal
> On my Ubuntu system I get kernel update failures because of some existing
> dpkg-statoverride rules. This led me to investigate how dpkg-statoverride
> works, and I discovered that there's an --update option that according to how
> I
> understand the man page ought to make it possible to update an existing
> override. But the option was already present in
> /etc/kernel/postinst.d/statoverride. That led me to look at the code.
>
> So the issue is that in src/statcmd.c:statoverride_add the logic seems flawed
> in the sense that it first checks that the file exists -- and errors out if it
> does -- then, if --update is specified, it checks again, and warns if it
> *doesn't* exist, but at this point it cannot exist, at least not unless
> --force
> is also specified.
It first checks if the statoverride exists on the database, and if it
does, allows it to proceed only if --force is given. If using --update,
it then checks if the pathname is present on the filesystem, and if it
does not exist, it then warns on verbose mode. Otherwise the
statoverride will be applied on the next dpkg unpack operation.
The --update option is used to update the pathname metadata on the
filesystem.
When setting up statoverrides the code needs to check if there's an
existing override, because if the admin set one up it needs to be
preserved. So whatever is doing this in Ubuntu seems to be buggy.
> My assumption would be that it should not be an error that the file exists
> when
> specifying --update.
You seem to be mixing up --force and --update. I'm thus closing this
report. But if after re-reading the man page it still seems unclear, I
guess we can try to clarify it.
Thanks,
Guillem
--- End Message ---
