Control: tag -1 + wontfix
Hello Yuri, 2015-08-12 16:29 Yuri D'Elia:
Package: aptitude Version: 0.7-1+b1 Severity: wishlist On development machines, when following unstable/experimental, it's sometimes helpful to be able to force installation/removal/downloadgrade of packages even if this results in deliberately breaking the system. It's a rare need, but this is something that comes in handy when going through a transition phase, without having to uninstall packages that are going to eventually get fixed. Since I have a /lot/ of development packages installed, often I don't care if some libraries break since I rarely use them, but I *do* want to keep them installed for the documentation, the headers, etc. In fact, many times I know exactly why a package would break another, and I know it's safe for me to perform the action anyway. When I'm at the preview mode, pressing 'g' again however doesn't allow me to continue if something is broken. Aptitude enforces a solution that doesn't break any package [and mind, I find this behavior to be absolutely correct]. But I would love to have an option in the preferencies that allows to get past that. In these cases, when pressing 'g' again at the preview, show a prompt in the likes of "warning: you're about to break ..., continue [yes] [no]" and proceed the installation with dpkg --force-all. We have something like that already, when trying to remove an essential package (oh boy, that is more annoying than it should ;)). Currently, when this happens, I basically do the installation manually with dpkg and all is well. But since aptitude still enforces a system without broken packages, as soon as one dependency is not fullfulled, nothing else can be done through aptitude anymore (besides fixing the package causing the problem). For this reason I also have to manipulate the package control flags themselves before installing, just to be able to use aptitude "normally". Let me break my system(tm).
It is an interesting idea and I had thought about the possibility sometimes in the past, but I think that aptitude and its resolver are complicated enough and have enough problems of its own as they are. It is also a very dangerous thing to play with, because for example it could allow to break something not obvious but related to system tools (e.g. any of the deps of aptitude, apt, dpkg), and then the system would have no way to recover. I think that making aptitude and the resolver more flexible and implementing what you request would be a bad idea in general at this point -- it will allow more unintended breakages, for little gain or edge cases like this; and the time taken to implement it could probably be better spent improving other areas of aptitude. So realistically, even if somebody finds a neat way to accomodate this featuer without breaking anything, it does not seem trivial and I do not see this happening any time soon, and so marking it as 'wontfix' at the moment. Cheers. -- Manuel A. Fernandez Montecelo <[email protected]>
