Bug#608884: dpkg-vendor: please document format of /etc/dpkg/origins/ files
Package: dpkg Version: 1.15.8.6 Severity: wishlist Hello, in order to properly resolve #607850 we'd like to know the full specification of /etc/dpkg/origins/ files (we couldn't find the documentation). Thanks in advance, Sandro -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.31-1-amd64 (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/bash Versions of packages dpkg depends on: ii coreutils 8.5-1 GNU core utilities ii libbz2-1.01.0.5-6high-quality block-sorting file co ii libc6 2.11.2-1 Embedded GNU C Library: Shared lib ii libselinux1 2.0.89-2 SELinux runtime shared libraries ii xz-utils 4.999.9beta+20100713-1 XZ-format compression utilities ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime dpkg recommends no packages. Versions of packages dpkg suggests: ii apt 0.8.10 Advanced front-end for dpkg -- no debconf information -- 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#548415: reportbug: Package upgrade information in bug reports
Processing commands for cont...@bugs.debian.org: > clone 548415 -1 Bug#548415: reportbug: Package upgrade information in bug reports Bug 548415 cloned as bug 608930. > reassign -1 dpkg Bug #608930 [reportbug] reportbug: Package upgrade information in bug reports Bug reassigned from package 'reportbug' to 'dpkg'. Bug No longer marked as found in versions reportbug/4.8. > retitle -1 please provide a tool to parse dpkg.log* files Bug #608930 [dpkg] reportbug: Package upgrade information in bug reports Changed Bug title to 'please provide a tool to parse dpkg.log* files' from 'reportbug: Package upgrade information in bug reports' > block 548415 by -1 Bug #548415 [reportbug] reportbug: Package upgrade information in bug reports Was not blocked by any bugs. Added blocking bug(s) of 548415: 608930 > thanks Stopping processing here. Please contact me if you need assistance. -- 548415: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548415 608930: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=608930 -1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=-1 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#608829: dpkg-dev - dpkg-source rejects valid patch files
Hi! On Mon, 2011-01-03 at 21:41:57 +0100, Raphael Hertzog wrote: > On Mon, 03 Jan 2011, Bastian Blank wrote: > > > I don't know whether I'm going to accept this request. I'm rather enclined > > > to tag it wontfix. But I welcome supplementary feedback. > > > > Okay, another nail in the cofin of the quilt source format. It looks > > like a mistake to even thought about using it. > > I haven't taken any decision yet, but you're the first to complain about > this particular (mis-)feature so it can't be so annoying as you make it > sound like. > > Or maybe I should turn it into a warning and not die. I personally don't see any harm in allowing it, even w/o a warning. ISTR using this at some point in the past with v1 sources and quilt patches when manually editing something (for whatever reason) and appending a new hunk for an existing patches file which belonged in the same logical patch. I don't think I've had the need for this at all lataly, given that I tend to refresh the patches to avoid fuzzies. But I can see how not divering from an upstream provided patch makes sense, although then that argument does not apply if one ends up concatenating them anyway. There's though still the possible argument that the patch is like that upstream already. 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#21941: dpkg usage of /var
tag 21941 wontfix thanks [ Goswin, removing the wontfix tag is not something for you to decide. ] On Sun, 2010-12-26 at 16:56:49 +0100, Andreas Barth wrote: > re usage of /var: > > dpkg puts the package data into /var/lib/dpkg/info. This includes the > list of files, the list of conffiles, templates, md5sums and also the > maintainer scripts of each package. > > According to FHS: > | /var contains variable data files. This includes spool directories and > | files, administrative and logging data, and transient and temporary > | files. > re /var/lib: > | This hierarchy holds state information pertaining to an application or > | the system. > > The usage of /var/lib/dpkg matches that description IMHO. ... as those files are clearly state for dpkg. Those scripts are variable in the sense that they might appear, disappear, or change during a dpkg run. So the location seems perfectly fine to me. It's more relevant though the snippet Goswin pasted: | /var/lib/ is the location that must be used for all distribution | packaging support. Different distributions may use different names, of | course. The same equivalent path rpm is using for example. And thus I don't see the point in changing the current location. Even if the /usr/lib location could be interpreted and argued as valid too, I'd not see the point in changing it, given the coding and transition work involved, susceptible to system breakage, and unfortunately also because there are programs out there which rely on those paths (which could be solved with symlinks, but then we'd be getting into really ugly territory, for no really good reason). But mostly given the solution below. > possible ways for /var to be no-exec > [...] > per local admin > 4. remount /var with exec > ~ > AFAICS there is no option within dpkg (or not documented) to always > execute commands prior to an dpkg "writing" invocation (while there is > within apt). It might make sense to remount /var with exec in case > it's noexec before running any scripts. > I think adding hooks for dpkg to run scripts pre-/post-changing > requests (e.g. configure, remove, install, ...) might make sense. There's already the invoke hooks (see man dpkg), present since 1.15.4, which allow just that. 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#21941: dpkg usage of /var
Processing commands for cont...@bugs.debian.org: > tag 21941 wontfix Bug #21941 [dpkg] scripts under /var prevent mounting /var with noexec Added tag(s) wontfix. > thanks Stopping processing here. Please contact me if you need assistance. -- 21941: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=21941 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
