ronin2@bellatlantic.net wrote: > I'm saying there are probably several ways to resolve this, but throwing > out a binary (without an available upgrade) because the doc package for > a later release is available is not one of them. Well, the normal apt behavior when you request to install a particular package and that package conflicts with things you already have installed, is that it assumes you were serious about wanting to install the new package, and warns you that this will require the removal of the others. You can then cancel the changes if you want. This is reasonable behavior, and it's simple, consistent, and easy to understand. If you're suggesting that the installation of a new doc package over a conflicting, previously-installed binary package should be different than if it were the other way around (previously-installed doc package, new binary), then I don't at all agree. A package is a package is a package. Apt shouldn't treat one package differently from another just because of the section it's in. I think when you describe the specific case of an upgraded doc package for which a corresponding binary package is not yet available, you are assuming too much knowledge on apt's part. It probably has no idea that sylpheed and sylpheed-doc are related. It knows about declared dependencies and conflicts, and that's it. So if sylpheed-doc_X conflicts with sylpheed_X-1, that's no different than libfoo-c102 conflicting with libfoo (which we got in the gcc-3.2 transition for C++ libraries). Now, if sylpheed-doc had "Depends: sylpheed", that probably would have done what you wanted, but why should the documentation depend on the program? Shouldn't I be able to read about a program without installing it first? Now, if I have both the program and the docs installed, it's not unreasonable to want the two to be in sync (otherwise users might be confused by inconsistencies between them), but I don't think you can express that in package dependencies, because the dependency isn't of one package on the other, but merely that the two be in sync IF both are installed. Having each package conflict with outdated versions of the other is the closest you can get, I believe. And that's what sylpheed and sylpheed-doc do. Craig
Attachment:
pgpW63isVoLJ0.pgp
Description: PGP signature