Bug#650077: dpkg: The Installed-Size estimate can be wrong by a factor of 8 or a difference of 100MB
Package: dpkg Version: 1.16.1.2 Severity: wishlist Symptom ~~~ I just installed libjs-mathjax. According to its Installed-Size this would just consume 16512KB. Now according to policy this is just an estimate of course. But how accurate is it actually? So I installed said package on ext3. Turns out /usr/share/javascript/mathjax takes up 127296KB and /usr/share/doc/mathjax takes another 1200KB. So our estimate is wrong by a factor of 8 or a difference of 100MB. This estimate is also used to determine whether the disk has enough space, so if my disk just had 50MB left, aptitude would have tried to install this package and failed. The actual problem ~~ Problems with Installed-Size are not exactly new as discussion in http://bugs.debian.org/534408 (unit for Installed-Size) and http://bugs.debian.org/630533 (usage of du --apparent-size) have shown. So what is different this time? Installing the very same package on a btrfs yields a size that is much closer to the listed Installed-Size. (I don't have any numbers on this.) So whatever dpkg puts into this field, it *will* be wrong somewhere. The policy already mentions that this estimate cannot be accurate everywhere, but in fact it will be wrong by a factor of at least 2.5 (=sqrt(8)) or a difference of at least 50MB (=100MB/2) somewhere. Any attempt to change the computation of this value thus cannot fix this bug. Discussion ~~ In the example of libjs-mathjax the reason for the huge difference is the inclusion of a large number of very small files. Some filesystems allocate a block for each of these files and others are able to store multiple files in a block. A simple approach could be to include an additional field (Installed-Files?) that returns the number of files in the package. A second estimate for the Installed-Size would then be given by the number of files times the block size. The maximum of both estimates could be used. It would solve the immediate symptoms with libjs-mathjax. It is not without problems though. For instance I did not explain what block size to use. An administrator may have different file systems set up for / and /usr. Also the question remains whether this feature is worth the associated effort. To get discussion going I pull in debian-policy@l.d.o. Helmut -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2026110639.ga30...@alf.mars
Bug#628515: recommending verbose build logs
Hi Matthias, Matthias Klose wrote: It's always interesting to look at build logs, or to receive bug reports of the form CC compiler error message or CCLD linker error message without knowing how the compiler or the linker were called. Maybe it is convenient for a package maintainer watching the build scrolling by (some of these are even colorized), but lacking this kind of information in the first place seems to be the wrong thing. So please let us deprecate this anti-feature and recommend verbose build logs by default and only turn them off by request (e.g. with DEB_BUILD_OPTIONS=noverbose). As much as I agree with your goal (being able to easily understand and diagnose miscompilations and build failures) I do not suspect there is a consensus for this. Some maintainers enjoy reading abbreviated build logs, where error messages and warnings stand out. So how can we make progress anyway? I would propose introducing something very similar to what you mentioned above, but just flipping the default. People who want verbose build logs could use DEB_BUILD_OPTIONS=verbose Then I think there would be a strong case for making that the default on autobuilders, but that's a separate question, anyway. Strawman patch below. What do you think? diff --git i/policy.sgml w/policy.sgml index 31226328..34a195f1 100644 --- i/policy.sgml +++ w/policy.sgml @@ -2224,6 +2224,17 @@ stripped from the binary during installation, so that debugging information may be included in the package. /item + tagverbose/tag + item + This tag means that compiler and linker commands used to + build the package should not be abbreviated in the + log.footnote + Packages built with ttcmake/tt, autotools, or + the Linux kernel build system can implement this by + passing the parameters ttV=1/tt and + ttVERBOSE=1/tt as arguments to ttmake/tt. + /footnote + /item tagparallel=n/tag item This tag means that the package should be built using up -- -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2027003703.ga9...@elie.hsd1.il.comcast.net
Timeline for 3.9.3 ?
Dear Policy maintainers, the 3.9.2 release happened last April, and since then 9 bugs were closed, about syntax of control files, japanese fonts, the machine-readable copyright file format, and the Perl and Motif policies. I wonder what is the timeline for a 3.9.3 release. I of course have DEP 5 in mind. Although it is not known when the DEP will be released, there are no open isssues under discussion about blocking bugs, so a relase could happen soon (in comparison with the length of the project). If the DEP would happen to be declared accepted at a time where an upload of the debian-policy package is planned, that could be a great synergy to benefit from. Therefore, I offer my help to work on issues that you would like to be included in Policy 3.9.3. I am trying to do some basic triaging at a very small pace, but given the size of the bug list, I am quite unlikely to find relevant issues by chance without your instructions. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2027015729.ga9...@merveille.plessy.net
Bug#630174: debian-policy: forbid installation into /lib64
user debian-policy@lists.debian.org tag 630174 + patch usertags 630174 + normative thanks Le Sat, Jun 25, 2011 at 04:28:41PM -0500, Steve Langasek a écrit : On Sat, Jun 11, 2011 at 10:58:02PM +0200, Julien Cristau wrote: On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote: Currently, section 9.1.1 relaxes the FHS requirement that /lib64 and /usr/lib64 be used, but it doesn't prohibit installing files in that location. However, due to the way Debian handles this (with symlinks), bad things happen in terms of tracking files and conflicts if packages install files into /lib64 and /usr/lib64 and rely on these symlinks. I think we should instead prohibit (must not) installing files into /lib64 and /usr/lib64 in packages with architecture amd64. Sounds sensible to me. I agree. Here is a patch. According to apt-file, prohibiting to install files into /lib64 and /usr/lib64 on amd64 would make only one package RC-buggy, juffed, in its experimental version. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan From 8a708ce2125835e537566fc1f75094d91076f573 Mon Sep 17 00:00:00 2001 From: Charles Plessy ple...@debian.org Date: Sun, 27 Nov 2011 11:40:21 +0900 Subject: [PATCH] Forbid installation into /lib64 and /usr/lib64. Closes: #630174 --- policy.sgml |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/policy.sgml b/policy.sgml index 3122632..47fbfb4 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6185,8 +6185,8 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ /item item p - The requirement for amd64 to use file/lib64/file - for 64 bit binaries is removed. + Packages with architecture amd64 must not install files + in file/lib64/file and file/usr/lib64/file. /p /item item -- 1.7.5.4
Processed: Bug#630174: debian-policy: forbid installation into /lib64
Processing commands for cont...@bugs.debian.org: user debian-policy@lists.debian.org Setting user to debian-policy@lists.debian.org (was ple...@debian.org). tag 630174 + patch Bug #630174 [debian-policy] debian-policy: forbid installation into /lib64 Added tag(s) patch. usertags 630174 + normative Bug#630174: debian-policy: forbid installation into /lib64 There were no usertags set. Usertags are now: normative. thanks Stopping processing here. Please contact me if you need assistance. -- 630174: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=630174 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.132236272612139.transcr...@bugs.debian.org
Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means
Dear Nicholas, this summer you have submitted a bug against the Debian policy, about “what the license information in the copyright file actually means”. After reading again the whole discussion, my feeling is that much of the answer would be actually be given by a resolution of http://bugs.debian.org/462996, about documenting more precisely what the Debian copyright file needs to cover. Would it be fine for you if I merged your bug report with #462996 ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2027030945.ga30...@plessy.org
Bug#633994: debian-policy: confusion over what the license information in the copyright file actually means
Hi Charles, Charles Plessy wrote: this summer you have submitted a bug against the Debian policy, about “what the license information in the copyright file actually means”. After reading again the whole discussion, my feeling is that much of the answer would be actually be given by a resolution of http://bugs.debian.org/462996, about documenting more precisely what the Debian copyright file needs to cover. I don't think so. Wasn't Nicholas's report about how to deal with cases where upstream permits License A or License B but the Debian maintainer for a package is only interested in one of the two (for example, how and whether to avoid distributing a copy of the GFDL-1.1, which is not part of common-licenses and whose terms do not comply with the DFSG, for a GFDL-1.1+ work)? -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2027031752.gb12...@elie.hsd1.il.comcast.net
Bug#630174: debian-policy: forbid installation into /lib64
On Sun, Nov 27, 2011 at 11:55:20AM +0900, Charles Plessy wrote: Le Sat, Jun 25, 2011 at 04:28:41PM -0500, Steve Langasek a écrit : On Sat, Jun 11, 2011 at 10:58:02PM +0200, Julien Cristau wrote: On Sat, Jun 11, 2011 at 13:49:53 -0700, Russ Allbery wrote: Here is a patch. According to apt-file, prohibiting to install files into /lib64 and /usr/lib64 on amd64 would make only one package RC-buggy, juffed, in its experimental version. I'm not sure why your apt-file invocation wouldn't have turned it up, but libc6 in unstable installs /lib64/ld-linux-x86-64.so.2. So as written this would make libc RC buggy, which is not what we want. (At the time of the previous discussion, libc was not installing this to /lib64; the change was made as a result of a more thorough analysis of the consequences of multiarch on i386 systems.) Also, this shouldn't spell out with architecture amd64. Packages on *all* architectures must avoid use of /lib64 and /usr/lib64, with a handful of exceptions. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org From 8a708ce2125835e537566fc1f75094d91076f573 Mon Sep 17 00:00:00 2001 From: Charles Plessy ple...@debian.org Date: Sun, 27 Nov 2011 11:40:21 +0900 Subject: [PATCH] Forbid installation into /lib64 and /usr/lib64. Closes: #630174 --- policy.sgml |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/policy.sgml b/policy.sgml index 3122632..47fbfb4 100644 --- a/policy.sgml +++ b/policy.sgml @@ -6185,8 +6185,8 @@ install -m644 debian/shlibs.varpackage/var debian/varpackage/var/DEBIAN/ /item item p - The requirement for amd64 to use file/lib64/file - for 64 bit binaries is removed. + Packages with architecture amd64 must not install files + in file/lib64/file and file/usr/lib64/file. /p /item item -- 1.7.5.4 signature.asc Description: Digital signature
Bug#630174: debian-policy: forbid installation into /lib64
Le Sat, Nov 26, 2011 at 09:52:57PM -0600, Steve Langasek a écrit : On Sun, Nov 27, 2011 at 11:55:20AM +0900, Charles Plessy wrote: According to apt-file, prohibiting to install files into /lib64 and /usr/lib64 on amd64 would make only one package RC-buggy, juffed, in its experimental version. I'm not sure why your apt-file invocation wouldn't have turned it up, but libc6 in unstable installs /lib64/ld-linux-x86-64.so.2. So as written this would make libc RC buggy, which is not what we want. (At the time of the previous discussion, libc was not installing this to /lib64; the change was made as a result of a more thorough analysis of the consequences of multiarch on i386 systems.) Also, this shouldn't spell out with architecture amd64. Packages on *all* architectures must avoid use of /lib64 and /usr/lib64, with a handful of exceptions. Thanks a lot for the corrections. After apt-file update I can indeed see libc6 and two additional packages, scidavis and ugene. About /lib64/ld-linux-x86-64.so.2, does that mean that the Policy has to list exceptions, (for files or packages ?), or that the proposal is obsolete ? For the architectures, I was puzzled that Russ mentionned ‘with architecture amd64’ in his proposal and tried to not discard this information. What achitectures, or which packages in which architectures, should be listed as exceptions ? I will update the patch or remove the patch tag according to the answers (hoping keep BTS control echo low). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2027042830.gc9...@merveille.plessy.net
