Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hello (again), to get a bit of traffic again in the discussion: I finally came around to implement disappear-support in APT [0] and it is already on his way for testers into the archive as 0.7.26~exp5. It is pretty basic and i still don't like the fact that we don't know about the disappear in advanced*, but anyway: std::setstd::string pkgPackageManager::GetDisappearedPackages(); can be used by the APT-frontends family to get a list of all packages which disappeared by actions handled with this instance. In apt-get this is implemented as a list of packages right at the end of the apt-get call - an example: The following packages disappeared from your system as all files have been overwritten by other packages: apt dpkg Note: This is done automatic and on purpose by dpkg. * (hint hint) 2010/4/10 David Kalnischkies kalnischkies+deb...@gmail.com: b) a) + overload Provides+Conflict+Replace + package managers can display it in advanced (renames) + package managers can prevent installation of oldPkg if newPkg is already installed. - doesn't handle more complex disappears in advanced Comments (on anything)? e.g. you might want to suggest a better wording? Best regards / Mit freundlichen Grüßen, David Kalnischkies [0] http://bzr.debian.org/loggerhead/apt/apt/debian-experimental-ma/revision/1968.1.51 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktikx02agnbubpnis595bgy_yqccpuo6eyi-_5...@mail.gmail.com
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hello (again), 2010/4/10 Jonathan Nieder jrnie...@gmail.com: David Kalnischkies wrote: he needs to install git-core which he does again after noticing that it doesn't work at the first try and face a conflict resolution process now… (or he had git already installed through some dependencies and is now immediately confronted with this conflict.) Why would he face a conflict resolution process? What i thought was: Hmm, the only content of oldPkg is a link from /usr/share/doc/oldPkg - /usr/share/doc/newPkg. newPkg includes also such a link. Installing newPkg will cause the disappear of oldPkg. If I try to install oldPkg again, what will happen? (I thought it would be forbidden by the conflict - misread sorry) After a quick test now with your testcase i noticed that oldPkg has his link back(?) without further notice (or is at least marked as installed). A follow up - maybe totally unrelated - dpkg call will cause the disappearance of oldPkg. As it is not untypical for APT to call dpkg multiple times in a row this will happen happen quite often in the same APT call. Assuming that someone will notice the one line disappearing in the dpkg output is a bit to much - i am happy enough if a user notice the remove section in the normal APT output before pressing 'y'. Many libapt-frontends doesn't even show the dpkg text - only a progress bar together maybe with the strings libapt emits on his status-fd. I guess the frontends will loose a lot of trust if users start to notice that they do something they haven't presented in advanced to the user: They REMOVE packages - by far the evilest thing a package manager can do… and additionally doesn't install a package they say they would install (apt-get install git-core). So in short: The frontends need to have a way to know in advanced that a package will disappear in my eyes so the user can be informed. I see a few options: a) disappear + --ignore-not-installed - yet another force flag -- and it will be passed to configure all the time, so it is maybe even better to have a flag to force dpkg to fail in this case than a flag to ignore this case. - package managers can only present this to the user as a fait accompli at the end of the run (if they parse --status-fd at all) b) a) + overload Provides+Conflict+Replace + package managers can display it in advanced (renames) + package managers can prevent installation of oldPkg if newPkg is already installed. - doesn't handle more complex disappears in advanced c) a new disappear status similar to removed-conffiles -- a new status - package managers will offer the remove in the next run, not in the run it could disappear - oldPkg can be reinstalled, will move to disappear and will be suggested to be removed in the next run again + package managers can display it in advanced (all) + handles even the complexest disappears d) drop of disappear completely, replace it with a transition section and some autoremove magic + package managers can display it in advanced (renames) + package managers can prevent installation of oldPkg if newPkg is already installed. (if it is not mixed with meta packages - so maybe we should move to debtags?) - no complex disappears allowed I currently would favor b) -- at least the common simple rename case can be presented easily in advanced. The same could be accomplished by d) but i like the difference between the rename which can really be done automatic and the remove of some no longer needed dependencies which the user need to check and approve. Best regards / Mit freundlichen Grüßen, David Kalnischkies -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2oc64043e61004100400k5f68bad5p9fe18d91e44ad...@mail.gmail.com
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi all, 2010/4/9 Jonathan Nieder jrnie...@gmail.com: Guillem Jover wrote: I've not checked but I'd expect this would imply only few lines of code on the apt side, just removing the just disappeared package from the to be configured queue. From my reading of pkgDPkgPM::ProcessDpkgStatusLine, APT does not care much about statusfd. It is treated as just some information about progress to pass to the end-user. APT only processes the line to add progress information and to translate the status changes so it doesn't need to be translated in every frontfrontend again. If both would be done in dpkg we (as in APT and Co. ) frontbackends could simply pass it through to someone who has real interest in it. Currently, this map does not affect APT’s order of operations. Instead, the list of operations is planned in advance and followed rigidly, regardless of the situation in the field. If i would have something to say i would push the complete planing in which order packages need to be configured to dpkg which i tried with my no-triggers options and succeeded to some extend: The only problem is that packages doesn't run awaited triggers of their pre- dependencies on unpack while configure does it for dependencies (#526774). With a few options enabled APT does only unpack all the stuff and configure -a at the end -- with the exception of the bug (?) above and packages it applies immediate configuration on, but these could be also configure -a calls instead of an explicit naming of the packages… (still the progress reporting need to be solved which is the sole reason the options aren't per default on already as they work otherwise and even avoid some problems…) My personal dream is it that APT would call dpkg with a list of packages the user want to see installed and/or removed/purged and dpkg would figure out an order in which the packages need to be unpacked/configured or removed as it has some informations handy which APT simply has not: The disappearing is one simple thing, but it can also provide better progress information as it knows which triggers are still awaiting and it even could break circular dependencies as it knows which packages have maintainer scripts which is again knowledge you can't easily transport to APT. A high-level package manager that collaborates with the user to deal appropriately with problems as they come might be a lovely thing. apt-get uses a simpler approach: to fix problems, you run it again. APT has a Dpkg::StopOnError option which defaults to true and in the false case simply proceeds with the next action as nothing had happened before, but if something failed in a maintainer script or dpkg APT can't do much to help the user anyway: The user needs to deal with the error as the program who knows best how to deal with the error (= the maintainer script or dpkg) has already given up. If they can't solve the problem, how APT could do it… Oh, and in a stable environment this shouldn't happen *knocks on wood*. :) The only countermeasure APT takes is to apply immediate configuration for essential and important packages (=unpack it and immediately configure them before starting to do work on unrelated optional packages). The idea of the proposed patch is to allow front-ends to make the same assumption. Only fair, but Guillem is right, APT already uses enough --force flags… It should be possible to dequeue the configure call based on the status-fd (i will give it a try now) through it feels a bit wrong and remembers me of my dream from above. ;) Best regards / Mit freundlichen Grüßen, David Kalnischkies -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/z2rc64043e61004090453r371cdeb9xdee967f396a39...@mail.gmail.com
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi (again), 2010/4/9 Guillem Jover guil...@debian.org: - When you upgrades your system by some high-level package manager it usually says you that 'packages oldpkg and newpkg will be upgraded' (or 'newpkg will be installed and oldpkg is upgraded'). Once oldpkg gets suddenly dropped, it's inconvenient (at least) to high-level package managers, may confuse users, and, in case, just a lie. If the package manager says it will upgraded, it should be upgraded and not removed. So even if it might be nice for the high-level front-ends to know before hand what will happen during a dpkg run, the fact is, it cannot be known and the front-end should be prepared to cope with unexpected state changes. There's more to the installation/removal process than just the metadata, there's the maintainer scripts which can fail at any point, there's file conflicts, there's triggers, etc. And then there's disappearing packages (even w/o an explicit Replaces). I think what Eugene means is that the (front)frontends of dpkg will have no way to display this action in the what will change if you confirm this action view. Packages could disappear without that this package is touched and even if it would be touched the displayed information is wrong, as a package which will disappear isn't really upgraded. Also, i think it feels a bit strange to apt-get install git-core with the result that the package git-core is not installed as it disappeared in the same call. I am just thinking about a Joe Sixpack reading a tutorial about git which says that he needs to install git-core which he does again after noticing that it doesn't work at the first try and face a conflict resolution process now… (or he had git already installed through some dependencies and is now immediately confronted with this conflict.) So maybe we should overload the Conflict+Replace+Provides triple for non purely virtual packages like mail-transport-agent to define that the real package with this name will disappear. (the current method for renaming us it too - the difference between both is the versioned replace and both have a versioned conflict, but pure virtual packages have no version, these three groups are distinguishable from each other). This isn't a complete solve - as far as i understand multiple packages could replace different files in a package causing it to disappear - but it would enhance the simple normal package rename case a bit. Best regards / Mit freundlichen Grüßen, David Kalnischkies -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/t2mc64043e61004090602i9273fa55h48315677b911e...@mail.gmail.com
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi, [ please CC c...@p.d.o as well in all future front-end-related issues too ] Guillem Jover wrote: Thirdly, IMO this 'disappear' thing is a design flaw in dpkg/policy: With this I disagree and I think it's a nice and useful feature to have. Features are always nice to have, unless they breaks the design, which is IMHO the case here. - Policy says that disappearted packages will not receive 'prerm' signal. Then, what's the point of having it when maintainer cannot guarantee it will be called? Regardless of it being possible to call prerm by making the code in dpkg more complex/intelligent, the thing is if it would be the correct thing to do. Something to consider is that a disappearing package is just one for which its files have been completely taken over by another package, so arguably its contents do not get removed, they just change ownership Eh? The 'master' package can overwrite files with the same paths but different context, so I don't consider them dpkgchown'ed. and no maintainer scripts do get called either on non-disappeared replaced files. Which is also bad IMO. So as I see it, the fact the the postrm gets called is more to notify that the package state is changing and it's going away (for which it might need to do additional cleanup) than that the files got removed (which didn't). The usual code run at prerm handles files getting removed which does not apply here, as no files have possibly gotten removed. That's non-technical. Or you guarantee, or you don't guarantee. Policy doesn't operate with 'more to notify' and 'usual code', fortunately. If the maintainer wrote that script prerm/postrm, it is important to do something in it. But if there was a demonstrable need to run prerm script in this situation, I'd not see any problem in an evaluation on adding such call. I wonder why that exception was added in policy then. - When you upgrades your system by some high-level package manager it usually says you that 'packages oldpkg and newpkg will be upgraded' (or 'newpkg will be installed and oldpkg is upgraded'). Once oldpkg gets suddenly dropped, it's inconvenient (at least) to high-level package managers, may confuse users, and, in case, just a lie. If the package manager says it will upgraded, it should be upgraded and not removed. So even if it might be nice for the high-level front-ends to know before hand what will happen during a dpkg run, the fact is, it cannot be known and the front-end should be prepared to cope with unexpected state changes. So that's probably the main point where we disagree. I consider this behavior as a severe design flaw, because dpkg play double standards here. It doesn't produce a sequence call for mass action by itself, passing that task to front-ends, but considering normal to modify it. FTR, in Cupt the code for generating such a sequence is a most complex thing, algorythmically, over the whole code base, beating such a monster as problem resolver. FTR2, the most popular implementation, libapt-pkg one, still has bugs regarding doing it. So, I would want to dpkg either implement this functionality itself or just do what front-end commands rather than notifying 'oh, I did something else, what next to do?'. The fact it cannot be known is another side of such of this flaw. If we forget for a minute about disappearing packages, it should be known. There's more to the installation/removal process than just the metadata, there's the maintainer scripts which can fail at any point, there's file conflicts, there's triggers, etc. It's not the problem of dpkg or front-ends. I think we are discussing a problem with good, polished packages, but failed upgrades. And then there's disappearing packages (even w/o an explicit Replaces). Eh? How a package can disappear without reverse Replaces or forced file conflicts ignoring? and because it makes it explicit so that the front-ends know exactly *why* the package is not there anymore and they can correct their view of the world accordingly. Well, you know, if I'm a driving a car on the road, I assume there are no walls on it. If you notify me a wall next 10 meters, I will success to change my mind, but avoiding the wall will be very hard. In this case (disappearing packages) it may be possible. But in general I disagree. - The use-case for 'fast transition' doesn't look good to me, because when user will try to install the package he/she will see 'the package does not exist' instead of installing newpkg and transitional oldpkg. I don't see the point of leaving cruft behind if the tools can automatically take care of completely replacing a package with another one. [...] This is a part I can agree with, though, stop. Hah. Correct me if I am wrong: new package got installed as a dependency of transitional package. So, it's automatically installed. Now, after upgrade the transitional package is removed, new package is alone and will be removed on next front-end
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
On Fri, Apr 09, 2010 at 06:32:34PM +0300, Eugene V. Lyubimkin wrote: This is a part I can agree with, though, stop. Hah. Correct me if I am wrong: new package got installed as a dependency of transitional package. So, it's automatically installed. Now, after upgrade the transitional package is removed, new package is alone and will be removed on next front-end run. Nice. Am I wrong? Not if ftp-master creates a 'metapackages' section (#574851) in which we can put transitional packages. The dependencies of packages within this section are not marked as automatically installed (or maybe they are currently, as APT::Never-MarkAuto-Sections:: is empty [#431737]). -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100409175734.ga3...@debian.org
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Julian Andres Klode wrote: On Fri, Apr 09, 2010 at 06:32:34PM +0300, Eugene V. Lyubimkin wrote: This is a part I can agree with, though, stop. Hah. Correct me if I am wrong: new package got installed as a dependency of transitional package. So, it's automatically installed. Now, after upgrade the transitional package is removed, new package is alone and will be removed on next front-end run. Nice. Am I wrong? Not if ftp-master creates a 'metapackages' section (#574851) in which we can put transitional packages. The dependencies of packages within this section are not marked as automatically installed (or maybe they are currently, as APT::Never-MarkAuto-Sections:: is empty [#431737]). I support this proposal partly (see my comment to #574851). -- Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com C++/Perl developer, Debian Developer -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bbf5443.80...@gmail.com
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi, David Kalnischkies wrote: he needs to install git-core which he does again after noticing that it doesn't work at the first try and face a conflict resolution process now… (or he had git already installed through some dependencies and is now immediately confronted with this conflict.) Why would he face a conflict resolution process? There is no reason I can see to conflict with a transitional package, after all. However, for git in squeeze, it’s a moot point. The 'transitional' archive section and front-end support for it [1] would be needed, or else the newly installed git package will be marked as automatically installed and promptly removed again. Thanks for the comments. Jonathan [1] See http://bugs.debian.org/574851 -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100410011500.ga25...@progeny.tock
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
On Thursday 08 April 2010 14:32:20 Jonathan Nieder wrote: I was reading some old material about trouble handling renaming binary packages in a seemless manner [1] [2]. My main thought: this shouldn’t be hard to fix. Hi Jonathan, Firstly, I'd ask you next time you CC de...@l.d.o, CC c...@packages.debian.org as well. Secondly, AFAIK, Guillem Jover some time ago added a notice of disappeared packages to --status-fd dpkg output, so theoretically any high-level package manager can use it (practically, I don't know whether apt uses/will use it or not, but cupt does not, due to to 'Thirdly' below). Thirdly, IMO this 'disappear' thing is a design flaw in dpkg/policy: - Policy says that disappearted packages will not receive 'prerm' signal. Then, what's the point of having it when maintainer cannot guarantee it will be called? - When you upgrades your system by some high-level package manager it usually says you that 'packages oldpkg and newpkg will be upgraded' (or 'newpkg will be installed and oldpkg is upgraded'). Once oldpkg gets suddenly dropped, it's inconvenient (at least) to high-level package managers, may confuse users, and, in case, just a lie. If the package manager says it will upgraded, it should be upgraded and not removed. - The use-case for 'fast transition' doesn't look good to me, because when user will try to install the package he/she will see 'the package does not exist' instead of installing newpkg and transitional oldpkg. Thanks for attention. -- Eugene V. Lyubimkin -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004081508.57002.jackyf.de...@gmail.com
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi! On Thu, 2010-04-08 at 15:08:56 +0300, Eugene V. Lyubimkin wrote: On Thursday 08 April 2010 14:32:20 Jonathan Nieder wrote: I was reading some old material about trouble handling renaming binary packages in a seemless manner [1] [2]. My main thought: this shouldn’t be hard to fix. Secondly, AFAIK, Guillem Jover some time ago added a notice of disappeared packages to --status-fd dpkg output, so theoretically any high-level package manager can use it (practically, I don't know whether apt uses/will use it or not, but cupt does not, due to to 'Thirdly' below). For reference, this was due to bug 537338. I've not checked but I'd expect this would imply only few lines of code on the apt side, just removing the just disappeared package from the to be configured queue. Thirdly, IMO this 'disappear' thing is a design flaw in dpkg/policy: With this I disagree and I think it's a nice and useful feature to have. - Policy says that disappearted packages will not receive 'prerm' signal. Then, what's the point of having it when maintainer cannot guarantee it will be called? Regardless of it being possible to call prerm by making the code in dpkg more complex/intelligent, the thing is if it would be the correct thing to do. Something to consider is that a disappearing package is just one for which its files have been completely taken over by another package, so arguably its contents do not get removed, they just change ownership, and no maintainer scripts do get called either on non-disappeared replaced files. So as I see it, the fact the the postrm gets called is more to notify that the package state is changing and it's going away (for which it might need to do additional cleanup) than that the files got removed (which didn't). The usual code run at prerm handles files getting removed which does not apply here, as no files have possibly gotten removed. But if there was a demonstrable need to run prerm script in this situation, I'd not see any problem in an evaluation on adding such call. - When you upgrades your system by some high-level package manager it usually says you that 'packages oldpkg and newpkg will be upgraded' (or 'newpkg will be installed and oldpkg is upgraded'). Once oldpkg gets suddenly dropped, it's inconvenient (at least) to high-level package managers, may confuse users, and, in case, just a lie. If the package manager says it will upgraded, it should be upgraded and not removed. So even if it might be nice for the high-level front-ends to know before hand what will happen during a dpkg run, the fact is, it cannot be known and the front-end should be prepared to cope with unexpected state changes. There's more to the installation/removal process than just the metadata, there's the maintainer scripts which can fail at any point, there's file conflicts, there's triggers, etc. And then there's disappearing packages (even w/o an explicit Replaces). The main reasons I chose to notify the front-ends via status-fd is so that we don't need to add yet another force option which in this case needs to be used always, and because it makes it explicit so that the front-ends know exactly *why* the package is not there anymore, and they can correct their view of the world accordingly. - The use-case for 'fast transition' doesn't look good to me, because when user will try to install the package he/she will see 'the package does not exist' instead of installing newpkg and transitional oldpkg. I don't see the point of leaving cruft behind if the tools can automatically take care of completely replacing a package with another one. I don't see the problem with the package not being installed any longer, that's exactly what was intended to happen, in addition dpkg should have notified via stdout and status-fd of what has happened, and I'd assume the package description would state the package is dummy/transitional/etc, so the situation should be pretty clear for the user. Also dpkg will not disappear a package currently being depended on. regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100409025754.ga28...@gaara.hadrons.org
Re: [PATCH dpkg 0/3] supporting seemless package renames (dpkg --configure --ignore-not-installed)
Hi, [quoting out of order for convenience] Guillem Jover wrote: I've not checked but I'd expect this would imply only few lines of code on the apt side, just removing the just disappeared package from the to be configured queue. From my reading of pkgDPkgPM::ProcessDpkgStatusLine, APT does not care much about statusfd. It is treated as just some information about progress to pass to the end-user. Strangely enough, helping the end-user in this way involves remembering the state of each package being operated on. When all is going to plan, APT can report that a package is half-installed --- Preparing foo unpacked --- Unpacking foo unpacked --- Preparing to configure foo half-configured --- Configuring foo installed --- Installed foo And there is a map from package names to integers indicating where in such a sequence each particular package is. Currently, this map does not affect APT’s order of operations. Instead, the list of operations is planned in advance and followed rigidly, regardless of the situation in the field. APT experts: would it make sense to build in additional intelligence of this kind? In other words, would it be safe and worthwhile to teach pkgDPkgPM::Go() to use the PackageOps map to skip a request to configure a package if it has disappeared? There's more to the installation/removal process than just the metadata, there's the maintainer scripts which can fail at any point, there's file conflicts, there's triggers, etc. AFAIK both APT’s and cupt’s approach is rather to hope everything goes according to plan and either do as much as possible or stop at the first error. A high-level package manager that collaborates with the user to deal appropriately with problems as they come might be a lovely thing. apt-get uses a simpler approach: to fix problems, you run it again. One final thought. dpkg itself does not use the kind of intelligence you are talking about to handle disappearing packages. It simply assumes that during an --install run, any package it is trying to configure that is not installed must have disappeared. The idea of the proposed patch is to allow front-ends to make the same assumption. For reference, this was due to bug 537338. Thanks for the pointer --- that was very helpful. Cheers, Jonathan Rough patch teaching APT to report processing: disappear lines: === modified file 'apt-pkg/deb/dpkgpm.cc' --- apt-pkg/deb/dpkgpm.cc 2010-03-26 15:04:49 + +++ apt-pkg/deb/dpkgpm.cc 2010-04-09 05:07:54 + @@ -50,6 +50,7 @@ std::make_pair(configure, N_(Configuring %s)), std::make_pair(remove,N_(Removing %s)), std::make_pair(purge,N_(Completely removing %s)), +std::make_pair(disappear, N_(Noting disappearance of %s)), std::make_pair(trigproc, N_(Running post-installation trigger %s)) }; @@ -407,7 +408,8 @@ 'processing: install: pkg' 'processing: configure: pkg' 'processing: remove: pkg' - 'processing: purge: pkg' - but for apt is it a ignored unknown action + 'processing: purge: pkg' + 'processing: disappear: pkg' 'processing: trigproc: trigger' */ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100409051011.ga9...@progeny.tock
