On Thu, 2009-11-12 at 12:02:34 +0200, Eugene V. Lyubimkin wrote: > reassign 555824 dpkg > thanks
> Firstly, this has nothing to do with cupt, I did the command manually. > Where did you see 'cupt' in the report? As you have reported similar reports in the past, I went and checked cupt sources and it seems to be passing those flags to dpkg (which is wrong), so instead of just closing the bug report I reassigned, which seems more useful. Anyway ... > Guillem Jover wrote: > > reassign 555824 cupt > > retitle 555824 cupt: Wrong use of --force-depends --force-conflicts > > thanks ... this still stands, but I'm not going to play bug ping-pong. > > On Wed, 2009-11-11 at 23:46:13 +0200, Eugene V. Lyubimkin wrote: > >> Package: dpkg > >> Version: 1.15.4 > >> Severity: grave > >> Justification: causes non-serious data loss > > > >> I had next packages installed on my system: perl-base, perl, > >> perl-modules, perl-doc (all from current unstable, 5.10.1-7). > >> > >> -8<- > >> sudo dpkg -i --force-depends --force-conflicts perl_5.10.1-8_amd64.deb > >> perl-doc_5.10.1-8_all.deb perl-modules_5.10.1-8_all.deb > >> perl-base_5.10.1-8_amd64.deb > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > >> [sudo] password for jackyf: > >> dpkg: considering removing perl-modules in favour of perl ... Here it says it will try this to get out of the situation... > >> dpkg: warning: ignoring dependency problem with removal of perl-modules: > >> perl depends on perl-modules (>= 5.10.1-7) > >> perl-modules is to be removed. > > > > [ ... More warnings on dependency problems. ... ] > > > >> dpkg: yes, will remove perl-modules in favour of perl. ... and here it confirms it will do just that. > >> (Reading database ... 140092 files and directories currently installed.) > >> Preparing to replace perl 5.10.1-7 (using perl_5.10.1-8_amd64.deb) ... > >> Unpacking replacement perl ... > >> Preparing to replace perl-doc 5.10.1-7 (using perl-doc_5.10.1-8_all.deb) > >> ... > >> Leaving `diversion of /usr/bin/perldoc to /usr/bin/perldoc.stub by > >> perl-doc' > >> Unpacking replacement perl-doc ... > >> Unpacking perl-modules (from perl-modules_5.10.1-8_all.deb) ... > >> Preparing to replace perl-base 5.10.1-7 (using > >> perl-base_5.10.1-8_amd64.deb) ... > >> Unpacking replacement perl-base ... > >> Setting up perl-base (5.10.1-8) ... > >> Processing triggers for man-db ... > >> Setting up perl (5.10.1-8) ... > >> Setting up perl-doc (5.10.1-8) ... > >> ->8- > >> > >> The result: the package 'perl-modules' is not installed (e.g. removed), > >> despite > >> the direct query to install new version, ignoring any dependency conflicts. > > > > Well, you asked for it, don't do that. As indicated by --force-help, > > usage of those specific options you used there “can seriously damage > > your installation” which is what happened. > Dpkg ignored the request to install new perl-modules. As said before, only because you asked it to. > Silently. It does not seem silent to me. Although it could repeat the message when actually doing the removal, but this would warrant a wishlist/minor bug report at most, if at all. > Why? I didn't read 'seriously damage your installation' as > 'ignore some command-line requests'. Ignoring dependency information, reads to me as can seriously damage your system, but YMMV. You asked to override those internal checks by way of force options. > > To try to get out of the situation dpkg tries to remove a package, > > because you added --force-depends then it ignored any problem and > > considered it an ok solution. The --force-conflicts gets considered > > later on. > > > Check what apt is doing. Cupt should not use force options on > > --unpack, --install, --configure or --triggers-only. Ideally no > > front-end would need to use force options, but using --force-depends > > on --purge and --remove seems kind of reasonable for now I guess. > Again, this has nothing to do with any high-level package manager. Well, then apart from the possible request for an additional removal printing I don't see any problem here. The upgrade works w/o the need for the force options (except for the unhandled /etc/perl/Net/libnet.cfg conffile, which does not get properly moved), and it causes major problems when using the force options (as expected), which should really *not* be used on normal operations, as said before. So, I'll be closing this soonish if no new info comes through. regards, guillem -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
