(ignoring M-F-T to add deity@ as I don't see a reason for dropping it & want to have apt discussions/decisions recorded there) On Wed, May 11, 2016 at 01:01:53PM +0200, Johannes Schauer wrote: > The package gcc-5-base is removed and installed as part of the same solution > because the EDSP format does not have an "Upgrade" action. As far as apt-cudf > or the solver is concerned the package must be removed in one of its version > and installed in another version. So from the solver's perspective having the > install and remove at the same time makes sense. From apt's perspective on the > other hand it would be sufficient to just have the "Install" request because > apt knows that it cannot co-install the same package in different versions, so > it is implicit that it will "remove" the old version. Its just a base property of Debian that a package can't be installed in multiple versions, so that "remove" is very very implicit as in: nobody is thinking about it, but I see that it would be needed if we would be talking about multiple versions. Compare commandline interfaces of apt and dpkg which do not have a concept of "upgrading" a package – just of upgrading the entire system or installing a specific package (in a new version). apt just invents this concept in terms of talking to the user – internally it couldn't care less. > I see three ways to fix this problem: > > 1. Apt should not override earlier actions by later actions but allow that a > package be removed in one version to be installed in another version as > part of the same request. I still haven't an overly strong opinion on this matter, mostly because I understand why either side of the fence came to believe that there is only their way of seeing it before stumbling over the other side. I just give 1. a very slight edge as the spec is very version focused and in this reasoning a remove/install combo makes more sense, while the default view of apt is more centered around packages (the API has no concept of installing a specific version – we install a package [in its candidate version]). Note that implementing this in apt means we rule out solvers who revert their decisions at runtime (as in streaming their decisions directly instead of solving the entire problem and communication the decisions in one big batch). That isn't really limiting, I just write it down here so I don't forget to mention it in the spec that you can't override actions sent earlier in the same run (if we do 1). > 2. Apt-cudf could not generate the "Remove" action at all in situations where > there is an "Install" action for the same package, thus not confusing apt. 2a makes in so far sense as versions aren't co-installable, so you would first need to remove it to install a new one… Anyway, as 2a is presumably a trivial change I would suggest implementing it as that is going to be easier to 'backport' than changes to apt will ever be, regardless of whatever else we do. (That is probably also the reason why this never was a problem in the last 5 years… someone must have tried upgrading a package before…) > Intuitively, I think option (1.) makes slightly more sense than the others > because the fact that an "Install" request of a higher version implicitly means High and lower is assuming too much: Think of downgrades for example. So the logic is more like "ignore a remove request if it is removing the currently installed version and the package was marked for installation previously". > the removal of a lower version is something apt encodes. Thus this assumption > should not be made further away from apt than necessary. Additionally, it seems The whole point of EDSP is to hide ugly details from apt (and as CUDF was in flux back then, also the implementation of that). You say its natural that a solver removes the old version before installing the new one – I say: it isn't. The solver needs to be told that it can't co-install multiple versions, probably with additional constrains not appearing in EDSP, but added by CUDF, as there would otherwise be no reason for it to remove the old version in the first place… So, "intuitively, I think option (2.) makes slightly more sense than the others because" of the above, but (1.) makes perfect sense, too. > But I'll not be the one implementing this in apt, so these are just my 2 cents. s|apt|apt-cudf| Best regards David Kalnischkies, who prefers blue bikesheds
Attachment:
signature.asc
Description: PGP signature