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
