Bug#822462: dpkg should automatically clean up obsolete conffiles (make rm_conffile unnecessary)
On Sun, Apr 24, 2016 at 02:20:50PM -0400, Daniel Kahn Gillmor wrote: > Currently, if a package drops a config file, the package maintainer > has to invoke: > > dpkg-maintscript-helper rm_conffile $CONFFILE $PRIOR_VERSION $PKGNAME -- > "$@" > > in the package's prinst, postinst, and postrm maintainer scripts. > > Instead, dpkg should be aware of the dropped config file and handle it > automatically. Are you suggesting that dpkg would diff the prior .conffiles with the in-.deb control file, and perform the equivalent of dpkg-maintscript-helper rm_conffile on each line that is deleted, and then make `dpkg-maintscript-helper rm_conffile` a no-op?
Re: Bug#843791: ghc: builds fail on hurd-i386: /usr/bin/ld: -r and -pie may not be used together
On Wed, Nov 09, 2016 at 05:47:13PM +0100, Samuel Thibault wrote: > It seems the latest ghc has troubles building packages on hurd-i386: > > [ 1 of 18] Compiling Data.Streaming.Zlib.Lowlevel ( > Data/Streaming/Zlib/Lowlevel.hs, > dist-ghc/build/Data/Streaming/Zlib/Lowlevel.o ) > ... > [18 of 18] Compiling Data.Streaming.Text ( Data/Streaming/Text.hs, > dist-ghc/build/Data/Streaming/Text.o ) > [ 1 of 18] Compiling Data.Streaming.Zlib.Lowlevel ( > Data/Streaming/Zlib/Lowlevel.hs, > dist-ghc/build/Data/Streaming/Zlib/Lowlevel.p_o ) > /usr/bin/ld: -r and -pie may not be used together That's confusing.
Bug#631757: thisname
Package: libdpkg-dev Version: 1.16.0.3 Please change the API so that the caller does not need to export thisname[]. It seems as though contextstring may be meant to serve in its stead, so perhaps an initial value could be passed to push_error_context(). -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457741: Bug#460158: zsh-doc would not install
On Fri, Jan 11, 2008 at 12:35:57AM +0100, arno renevier wrote: zsh-doc upgrade did not work today. I tried to uninstall, and reinstall, and it looks like package is uninstallable. Here is the output I get with aptitude install zsh-doc: This is bug #457741 on dpkg. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 10:52:45AM -0500, Manoj Srivastava wrote: What does this mean in non-git context? I think truncating the patch-log history is unimportant for Arch, but any ++pristine-trees should definitely be nuked prior to packing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 11:10:41AM -0500, Manoj Srivastava wrote:
Hmm. If I have just the ./{arch} directory, and none of the
files, then arch thinks the files have just been deleted; and you can't
just check out stuff, since the tree is up to date. Ah. Baz undo
restores all the files, cool.
I presume you could ship all the normal files in one tarball,
the .arch-ids and {arch} directories in another, and the debian/
directory in a third.
That would give the NMUer a full working tree to run $TLA diff
in. Only shipping a grab file would burden the end user with
a need for http access and no guarantee that the source will
be available.
The problem here is that the repository in question _has_ to be
registered by the user running this; so all the users would have to
register the arch repository in question before unpacking the source
tarball in order to tell baz/tla how to get access to the repo. Is this
going to be an issue?
It shouldn't be too difficult to add an --autoregister switch to tla
grab, though I don't know how safe it'd be.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, Oct 07, 2007 at 02:19:36PM -0500, Manoj Srivastava wrote:
Err, and why am I doing this? Why am I not shipping my working
directory as a tarball, complete instead of breaking it up
(apparently arbitrarily) into three parts?
As opposed to an .orig.tar.gz and all the debian/, {arch}/, and
.arch-ids/ components in the .diff.gz ?
How is git reconstituting the files if there is no network
access? Are they shipping all the bits needed to get a full working
dir without any network access?
Yes. the .git/ (or .bzr/ ) directory contains the entire (or abridged
in the case of these shallow clones) history so you can check out any
of the covered revisions.
This would be akin to you including a cachedrev of an arbitrary version
followed by all the subsequent patches.tar.gz files, except that I
believe git et al. are meant to be more space-efficient.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382673: [PATCH/RFC] dpkg-source.pl: Support a subset of wigpen on build
On Sun, Oct 07, 2007 at 03:17:49AM +0200, Frank Lichtenheld wrote: Hmm, I just noticed that dpkg-genchanges already uses -C, so it would be difficult to pass this option down from dpkg-buildpackage. Anyway, the name of the option is not really important at this point, yet. (-z perhaps? Seems to be free) Perhaps a long option instead? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Processed: Re: Processed: your mail
reassign 183209 dpkg,coreutils quit What's the point in debianutils Replacing something it Pre-Depends on?
Re: Processed: Re: Processed: your mail
Being able to overwrite some of its files of course. That's only relevant for the packages I can't modify, and in no circumstances should debianutils be overwriting coreutils's readlink.
Re: new fields in debian/control
Who said anything about that option only affecting the fields Wichert mentioned? Think about debian/rules that look for what origin they are building for, and take appropriate action. If you're going to use debian/rules to do conditional building for multiple origins you may as well conditionally set the Origin:. I imagine you could use check an environment variable and then place the appropriate variable in debian/substvars.
Bug#45121: dpkg: No option to rebuild /usr from /var/state
Hrmpf. dpkg is the low-level packaging tool, it needs to be fed the location of packages. The bug report was complaining that dpkg missed functionality; I showed it already possessed that functionality through a concrete example. Of course, for the sake of convenience, there should be a way to get it through a higher-level tool like apt or dselect, but that's beside the real point: dpkg already has what one needs to restore the system in the type of situation the reporter described. Perhaps the bug should be reassigned to apt, then. I know I've had a few instances where I needed to reinstall various packages and had to fudge the version numbers in the status file to get dselect or apt to refetch.
