On Mon, 2013-04-22 at 16:06:05 +0200, Helmut Grohne wrote:
> On Mon, Apr 22, 2013 at 07:31:54AM +0200, Guillem Jover wrote:
> > I guess a way to detect those could be piuparts runs that install
> > multiple instances of Multi-Arch:same packages, purge just one of
> > them, and compare that the packages created by the first instance
> > are not removed, and that other files do not get modified. Andreas,
> > would that be possible?
>
> A few months ago I looked at the archive for such cases. My technique
> was to download all M-A:same packages for one architecture, extract the
> maintainer scripts, look for suspicious commands and investigate. Of
> course this doesn't scale. At that time it resulted in the following bug
> reports:
>
> #695268
> #695271
> #695272
> #695275
>
> The small number highlights that this is not yet a frequent problem.
I think some others might had already been filed by Jonathan, and
subsequently fixed in the interim. It seems at least others from
Jonathan's list are missing bug reports.
But these seem to be the clear cases, and do not take into account
incorrect usage of dpkg-related tools. For example libwrap1 uses this
to do manual ref-counting:
"$(dpkg-query --show libwrap0 2> /dev/null | wc -l)" = 1
but this does not take into account dpkg selections, for example:
# dpkg-query -W libwrap0
libwrap0:amd64 7.6.q-24
# echo libwrap0:i386 install | dpkg --set-selections
# dpkg-query -W libwrap0
libwrap0
libwrap0:amd64 7.6.q-24
(Yes, I'll fix the strange non-archqualified output for selections in
dpkg 1.17.x.)
A correct way to do manual ref-counting could be:
# dpkg-query -f '${db:Status-Abbrev} ${binary:Package}\n' -W libwrap0 | \
grep -v '^.n' | wc -l
1
Other problems might be when maintainer scripts use the running dpkg
architecture instead of the package architecture (DPKG_MAINTSCRIPT_ARCH)
to decide when to do stuff, for example in libglib2.0-0.postrm.
> Given the complexity of these issues I tend to think the policy should
> discourage (as in "should not") the usage of shared resources in
> M-A:same packages. Then lintian could be used to warn about non-trivial
> maintainer scripts in M-A:same packages. Do others share that view?
Non-dpkg tracked files always require careful consideration, I don't
see anything special about this new case. During the huge ref-counting
thread it was decided that doing the package split was not desired
(less so for very few files), so bailing on it now would not seem
appropriate. I guess we might just need better documentation on how to
handle these cases. In the long term dpkg should just gain support for
registering arbitrary files and handle these itself.
Thanks,
Guillem
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130422152444.ga9...@gaara.hadrons.org
