Subject: silagra is a generic equivalent of the popular pfizer drug - msg#00234

Previous Message by Date: click to view message preview

Bug#255504: dpkg: config file replacement question is badly phrased

Package: dpkg Version: 1.10.22 Severity: minor When a new config file is installed, you get a question like this: Configuration file `/etc/dovecot.conf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** dovecot.conf (Y/I/N/O/D/Z) [default=N] ? o But the question (What would you like to do about it?) bares no relation to two of the options (Yes and No), which are also needlessly duplicated. Since this is long-time functionality, getting rid of it immediatly isn't an option, but they should at least be deprecated, or the question rewritten ("Do you want to use the new version?") so that the answer "yes" actually makes sense. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.22 Locale: LANG=C, LC_CTYPE=C Versions of packages dpkg depends on: ii dselect 1.10.22 a user tool to manage Debian packa ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an -- no debconf information

Next Message by Date: click to view message preview

Bug#255504: dpkg: config file replacement question is badly phrased

On Mon, 2004-06-21 at 14:46 +0100, Aquarion wrote: > When a new config file is installed, you get a question like this: > > Configuration file `/etc/dovecot.conf' > ==> Modified (by you or by a script) since installation. > ==> Package distributor has shipped an updated version. > What would you like to do about it ? Your options are: > Y or I : install the package maintainer's version > N or O : keep your currently-installed version > D : show the differences between the versions > Z : background this process to examine the situation > The default action is to keep your current version. > *** dovecot.conf (Y/I/N/O/D/Z) [default=N] ? o > > But the question (What would you like to do about it?) bares no relation > to two of the options (Yes and No), which are also needlessly > duplicated. > There is no "Yes" or "No" option; there is "install the package maintainer's version" and "keep your currently-installed version" which happen to be bound to the keys "Y" and "N", but these don't mean "Yes" or "No". Scott -- Have you ever, ever felt like this? Had strange things happen? Are you going round the twist? signature.asc Description: This is a digitally signed message part

Previous Message by Thread: click to view message preview

Bug#255504: dpkg: config file replacement question is badly phrased

Package: dpkg Version: 1.10.22 Severity: minor When a new config file is installed, you get a question like this: Configuration file `/etc/dovecot.conf' ==> Modified (by you or by a script) since installation. ==> Package distributor has shipped an updated version. What would you like to do about it ? Your options are: Y or I : install the package maintainer's version N or O : keep your currently-installed version D : show the differences between the versions Z : background this process to examine the situation The default action is to keep your current version. *** dovecot.conf (Y/I/N/O/D/Z) [default=N] ? o But the question (What would you like to do about it?) bares no relation to two of the options (Yes and No), which are also needlessly duplicated. Since this is long-time functionality, getting rid of it immediatly isn't an option, but they should at least be deprecated, or the question rewritten ("Do you want to use the new version?") so that the answer "yes" actually makes sense. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.22 Locale: LANG=C, LC_CTYPE=C Versions of packages dpkg depends on: ii dselect 1.10.22 a user tool to manage Debian packa ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries an -- no debconf information

Next Message by Thread: click to view message preview

Bug#239322: marked as done (Dependency should determine unpack order)

Your message dated Mon, 21 Jun 2004 21:44:48 +0200 with message-id <20040621194448.GA24492@xxxxxxxxxxx> and subject line Closing has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 22 Mar 2004 10:06:30 +0000 >From jdthood@xxxxxxxxxxx Mon Mar 22 02:06:30 2004 Return-path: <jdthood@xxxxxxxxxxx> Received: from mars.mj.nl [81.91.1.49] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1B5MKE-0000qS-00; Mon, 22 Mar 2004 02:06:30 -0800 Received: (qmail 26429 invoked from network); 22 Mar 2004 10:05:59 -0000 Received: from 81-91-5-95-customer.mjdsl.nl (HELO thanatos) (81.91.5.95) by www.mj.nl with SMTP; 22 Mar 2004 10:05:59 -0000 Received: by thanatos (Postfix, from userid 1001) id 8AB9210D60D; Mon, 22 Mar 2004 11:05:52 +0100 (CET) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Thomas Hood <jdthood@xxxxxxxxxxx> To: Debian Bug Tracking System <submit@xxxxxxxxxxxxxxx> Subject: Dependency should determine unpack order X-Mailer: reportbug 2.48 Date: Mon, 22 Mar 2004 11:05:52 +0100 Message-Id: <20040322100552.8AB9210D60D@thanatos> X-BadReturnPath: jdthood@xxxxxxxxxxxxxxxxxx rewritten as jdthood@xxxxxxxxxxx using "From" header Delivered-To: submit@xxxxxxxxxxxxxxx X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_12 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-7.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2004_03_12 X-Spam-Level: Package: dpkg Version: 1.10.19 Severity: wishlist Currently dpkg unpacks packages in the order that they are listed on the command line. In contrast, dpkg configures packages in an order that conforms to dependency relations. To illustrate this I created two packages, foo and bar, where bar Depends on foo. $ sudo dpkg -i foo_1.0_all.deb bar_1.0_all.deb Selecting previously deselected package foo. (Reading database ... 125693 files and directories currently installed.) Unpacking foo (from foo_1.0_all.deb) ... Selecting previously deselected package bar. Unpacking bar (from bar_1.0_all.deb) ... Setting up foo (1.0) ... Setting up bar (1.0) ... $ sudo dpkg --purge foo bar (Reading database ... 125698 files and directories currently installed.) Removing bar ... Removing foo ... $ sudo dpkg -i bar_1.0_all.deb foo_1.0_all.deb Selecting previously deselected package bar. (Reading database ... 125693 files and directories currently installed.) Unpacking bar (from bar_1.0_all.deb) ... Selecting previously deselected package foo. Unpacking foo (from foo_1.0_all.deb) ... Setting up foo (1.0) ... Setting up bar (1.0) ... In both cases, foo is configured before bar (good). However the unpack order depends on the order in which the packages are given on the command line. This is less than ideal. Sometimes it is important for the Depended-on package to be (not only configured but) unpacked before the Dependent package. This is the case, for example, if one package Replaces another and needs to replace the latter's conffiles. This only happens properly if the adopter is unpacked before the abandoner. The only way to enforce unpack order currently is by declaring a Pre-Dependency, but this is sometimes too strong a dependency. To give a specific example (the one that gives rise to this wish): initscripts needs to adopt conffiles belonging to an old version of sysvinit. The new version of sysvinit lacks the conffiles. For the adoption to go smoothly, initscripts needs to be unpacked before the new sysvinit package. It would be nice if this could be enforced by having the new sysvinit Depend on initscripts, but as things are we have to make the new sysvinit Pre-Depend on initscripts. There may be reasons why the unpack order should follow the command line order. If so, please explain and mark this report "wontfix". -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.4.24 Locale: LANG=en_IE@euro, LC_CTYPE=en_IE@euro Versions of packages dpkg depends on: ii dselect 1.10.19 a user tool to manage Debian packa ii libc6 2.3.2.ds1-11 GNU C Library: Shared libraries an -- no debconf information --------------------------------------- Received: (at 239322-done) by bugs.debian.org; 21 Jun 2004 19:46:23 +0000 >From jdthood@xxxxxxxxxxx Mon Jun 21 12:46:23 2004 Return-path: <jdthood@xxxxxxxxxxx> Received: from post-21.mail.nl.demon.net [194.159.73.20] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1BcUkI-0003cq-00; Mon, 21 Jun 2004 12:46:23 -0700 Received: from [82.161.38.140] (helo=localhost) by post-21.mail.nl.demon.net with esmtp (Exim 3.36 #2) id 1BcUkG-000GKW-00 for 239322-done@xxxxxxxxxxxxxxx; Mon, 21 Jun 2004 19:46:20 +0000 Received: by localhost (Postfix, from userid 1001) id 4EF1E12D33B; Mon, 21 Jun 2004 21:44:48 +0200 (CEST) Date: Mon, 21 Jun 2004 21:44:48 +0200 To: 239322-done@xxxxxxxxxxxxxxx Subject: Closing Message-ID: <20040621194448.GA24492@xxxxxxxxxxx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040523i From: jdthood@xxxxxxxxxxx (Thomas Hood) Delivered-To: 239322-done@xxxxxxxxxxxxxxx X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_25 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no version=2.60-bugs.debian.org_2004_03_25 X-Spam-Level: I am withdrawing this wish because I think that Pre-Depends is needed anyway in the cases I have in mind. -- Thomas Hood