Bug#617299: dpkg-deb: should give a hint when it fails due to filling /tmp
On Fri, Jul 13, 2012 at 08:46:51PM +0300, Martin-Éric Racine wrote: 2012/7/13 Martin-Éric Racine martin-eric.rac...@iki.fi: Package: dpkg Version: 1.16.4.3 Followup-For: Bug #617299 I also encounter the same bug when trying to build kernel 3.2.21 from upstream tarball: $ LOCALVERSION=-git-686-pae make deb-pkg [...] dpkg-deb: building package `firmware-linux' in `../firmware-linux_3.2.21-git-686-pae-1_i386.deb'. dpkg-deb: building package `linux-headers-3.2.21-git-686-pae' in `../linux-headers-3.2.21-git-686-pae_3.2.21-git-686-pae-1_i386.deb'. dpkg-deb: building package `linux-libc-dev' in `../linux-libc-dev_3.2.21-git-686-pae-1_i386.deb'. dpkg-deb: building package `linux-image-3.2.21-git-686-pae' in `../linux-image-3.2.21-git-686-pae_3.2.21-git-686-pae-1_i386.deb'. dpkg-deb (subprocess): data member: internal gzip write error: 'File not found' dpkg-deb: error: subprocess compress from tar -cf returned error exit status 2 make[1]: *** [deb-pkg] Error 2 make: *** [deb-pkg] Error 2 This seems to be caused by either 'tar' or 'gzip' using /tmp to build the package. Since recent Debian systems default to using tmpfs for /tmp, systems with insufficient memory or with another process using all available memory resources will make the build fail. Would there perhaps be a way to make this process use /var/tmp or some other normal storage space to avoid these nonsensical failures? No, switching to /var/tmp would make no sense and would in no way fix the bug. Nothing garanties that /tmp has enough space or that /var/tmp would have enough space or the build directory. Applications have to deal with ENOSPC properly. The bug here is that the error message makes little sense. It should properly respond with No space left on device and hopefully give a hint that the device in question is /tmp. And the trigger seems to be the excess size of the build, see other mails. But fixing that is just doctoring the symptoms. MfG Goswin -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#273093: dpkg: Unpredictable behavior when two packages want to divert the same file
reassign 273093 debian-policy retitle 273093 policy: Document interactions of multiple clashing package diversions severity 273093 wishlist thanks Hi! On Thu, 2004-09-23 at 22:25:58 +0200, Frank Küster wrote: Package: dpkg Version: 1.10.23 Severity: normal Feel free to reassign this to debian-policy if you think this isn't dpkg's fault... Doing this now. If the two independent packages bar and baz both dpkg-divert the file /usr/share/foo/bla/brm of package foo, only one of both can get the diversion. And it will be the first package that can successfully register the diversion, the second will just get Unpacking baz (from .../apt/archives/baz_1.0-3_all.deb) ... Leaving `diversion of /usr/share/foo/bla/brm to /usr/share/foo/bla/brm.foo by bar' Setting up baz (1.0-3) ... and even when bar is removed, no record is made that baz wanted to add it's own diversion. This sould only happen if both diversions are idential, which would be fine, but most commonly if two different packages divert a file then the --package argument will be different which will make dpkg-divert error out pointing out there's a clash with an existing diversion, and this has (supposedly) been this way since the initial dpkg-divert implementation. This can lead to unpredictable behavior, because it's just a matter of chance which package is installed first by a user. It seems there is no mention of the problem in policy (or the developer's reference). It also seems I don't like the diversion mechanism too much... Anyway, making this predictable and defined seems ;-) to be difficult, both by implementing checks and registries in dpkg, or by policy decisions. I have no proposal to make, unfortunately. And while we're at it, and a copy goes to debian-policy@l.d.o, , | You should not use `dpkg-divert' on a file belonging to another | package without consulting the maintainer of that package first. ` Not only that a warning about multiple diversions is missing here: This should be noted down somewhere in the source package. There are NMUs, packages are orphaned etc., and information like this can easily be lost. I don't see anything to fix here in dpkg, this is how diversions work, that's just it. It could of course be documented more clearly in policy, and for example mention that different packages diverting the same file should Conflict with each other. thanks, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#273093: dpkg: Unpredictable behavior when two packages want to divert the same file
Processing commands for cont...@bugs.debian.org: reassign 273093 debian-policy Bug #273093 [dpkg] dpkg: Unpredictable behavior when two packages want to divert the same file Bug reassigned from package 'dpkg' to 'debian-policy'. No longer marked as found in versions 1.10.23. Ignoring request to alter fixed versions of bug #273093 to the same values previously set retitle 273093 policy: Document interactions of multiple clashing package diversions Bug #273093 [debian-policy] dpkg: Unpredictable behavior when two packages want to divert the same file Changed Bug title to 'policy: Document interactions of multiple clashing package diversions' from 'dpkg: Unpredictable behavior when two packages want to divert the same file' severity 273093 wishlist Bug #273093 [debian-policy] policy: Document interactions of multiple clashing package diversions Severity set to 'wishlist' from 'normal' thanks Stopping processing here. Please contact me if you need assistance. -- 273093: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273093 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668400: /usr/bin/apt-get: Apt-get purge/remove delete file behind symlink
On Wed, 2012-04-11 at 17:47:15 +0200, Rafal Kaminski wrote: Package: apt Version: 0.8.15.10 Severity: normal File: /usr/bin/apt-get I found some bug or feature apt-get. I've installed tomcat7 and in folder /etc/tomcat7 I put symlink to diff. folder - like to /data/file1. Then in /etc/tomcat7 I had symlink file1. When I made apt-get remove tomcat7 or apt-get remove --purge tomcat7 - apt-get didn't remove symlink from /etc/tomcat7, BUT REMOVE file from /data. After apt-get remove I hadn't file1 in /data/file1. Given the directory removals in tomcat7's postrm script I'm inclined to think this is tomcat7 (and tomcat6) fault, but it would be helpful to know what exactly did you symlink, was it the /etc/tomcat7 directory itself, one of the conffiles inside? Something else? regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667438: Support file triggers on /usr/local, manually triggered by administrator after make install
Hi!
On Wed, 2012-04-04 at 03:39:54 -0700, Josh Triplett wrote:
On Wed, Apr 04, 2012 at 11:43:48AM +0200, Raphael Hertzog wrote:
On Wed, 04 Apr 2012, Josh Triplett wrote:
In some way we already do:
$ sudo dpkg-trigger --no-await /usr/local/man
$ sudo dpkg --configure -a
Processing triggers for man-db ...
But there's easy way to find out all the file triggers that match
/usr/local/something.
I meant there's no easy way.
running spuriously, triggering *everything* seems acceptable for a first
pass. A quick (untested) prototype version:
find /usr/local -exec dpkg-trigger --no-await '{}' \;
dpkg-trigger will only accept names of existing triggers. That's why I was
telling that you would need a way to extract a list of file triggers.
Oh, I see. I would have expected dpkg-trigger /path/to/file to
trigger triggers for /path/to, not just /path/to/file. But it looks
like that doesn't work.
That's been fixed now in dpkg 1.16.4.
(The find command I suggested should still work, since it'll trigger all
parent paths as well, so unless a package had interest /usr or
interest /, it should work. But the more optimized version that only
triggers on changed files would not work, without explicitly triggering
all parent directories as well.)
In any case just as a clarification, dpkg-trigger does not do any
significant work, it does not even check if there's matching triggers,
it just queues them so that later on whenever dpkg is run it can
process those triggers, trimming out any that do not match, and
triggering each one only once even if some paths would match several
times.
Then you can easily match file triggers with files installed in
/usr/local/.
Rather than trying to parse triggers here, why not just add an option to
dpkg-trigger which says to interpret the argument as a filename,
precisely as it would when dpkg wants to install/modify a file with that
name, and trigger any triggers which care about either that name or any
parent directory?
Thus, while dpkg-trigger /path/to/file only triggers a package that has
interest /path/to/file, dpkg-trigger --filename /path/to/file would
trigger a package with interest /path/to as well.
As per above, that's now the current behaviour, but not only for
filenames it applies to any path, including directories.
(Preferably, dpkg-trigger should take an arbitrary number of filenames
rather than just one, but that just represents an optimization.)
Here the optimization would only consist of reducing the amount of
calls to dpkg-trigger, but the amount of activated triggers would not
change a bit, so given that this usage does not seem common, I'd rather
not add this. If it really becomes extremely cumbersome or it's shown
to take too much time, then I'd be open to consider this (as a separate
bug report, though).
Having such an option seems preferable to manually extracting lists of
existing file triggers and parsing them. In particular, it would also
work for any future extensions to file triggers (such as more intricate
include/exclude logic).
So given all the above, I don't see anything else really needed from
the dpkg side, and the proposed update-local could be implemented and
added in some other existing package right away.
As such I think we can close this bug report?
thanks,
guillem
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
