Control: tag -1 + patch Hi, Quoting David Kalnischkies (2016-05-11 20:44:05) > > 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…) it seems there is an easy explanation why this problem wasn't spotted earlier. Dose3 commit c0d57a2a, titled "Minor changes to apt-cudf" is in dose3 since upstream version 4.1 and if I read the diff correctly, it switches the order of "Install" and "Remove" requests around: https://scm.gforge.inria.fr/anonscm/gitweb?p=dose/dose.git;a=commit;h=c0d57a2a6f71649e8aa5fbe2323e06b126f69230 > > 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". Right. Please replace "higher" by "different" in my message. > > 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| Nope, I actually meant apt, as I'm the one doing it for apt-cudf. ;) So despite the danger that providing a patch will kill this discussion, the attached patch (and also upstream branch user/josch/apt-cudf-remove) makes sure that removal requests are not generated for package names that were earlier marked as installed. Thanks! cheers, josch
From 27afc8f6d290dd7f31a6bcde6b8761d0b55e87bd Mon Sep 17 00:00:00 2001
From: Johannes 'josch' Schauer <josch@mister-muffin.de>
Date: Thu, 12 May 2016 06:37:47 +0200
Subject: [PATCH] applications/apt-cudf.ml: Do not generate removal requests
for up/downgrades
As far as solvers are concerned, changes in package versions mean that
the old package is removed and the package in the new version is
installed. This is how it was encoded in the EDSP output so far.
Recently, (commit c0d57a2a) the order of installation and removal
requests was turned around and it was discovered that apt will only
parse the *last* request for a package (see Debian bug #823906). Thus,
apt would remove a certain package but not install it in its new
version.
As a remedy, this commit makes sure that package up or downgrades are
expressed in a single "Install" request and that these do not show up as
a "Remove" request anymore.
---
applications/apt-cudf.ml | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/applications/apt-cudf.ml b/applications/apt-cudf.ml
index 29eb7b5..90fd450 100644
--- a/applications/apt-cudf.ml
+++ b/applications/apt-cudf.ml
@@ -506,10 +506,19 @@ let main () =
Util.Timer.start timer3;
let empty = ref true in
let cache = CudfAdd.Cudf_hashtbl.create 1023 in
+ (* In Debian (and thus for apt and dpkg), packages can only be installed in a
+ * single version at a time. Thus, any up or downgrades always implicitly
+ * remove the old version. Therefore, if a package installation request just
+ * changes the version of the package, we remember this in a hash table such
+ * that we do not generate a removal request for that package as well. As a
+ * result, every package (name) only shows up exactly once in the solution.
+ * Package removals are not explicitly shown for upgrades. *)
+ let notremoved = Util.StringHashtbl.create 1023 in
let (install,remove) = CudfDiff.make_solution ~universe ~solution:soluniv in
CudfAdd.Cudf_set.iter (fun pkg ->
CudfAdd.Cudf_hashtbl.add cache pkg ();
+ Util.StringHashtbl.add notremoved pkg.Cudf.package ();
Format.printf "Install: %a@." pp_pkg (pkg,univ)
) install;
@@ -527,7 +536,8 @@ let main () =
) cudf_request.Cudf.install;
CudfAdd.Cudf_set.iter (fun p ->
- Format.printf "Remove: %a@." pp_pkg (p,univ)
+ if Util.StringHashtbl.mem notremoved p.Cudf.package then ()
+ else Format.printf "Remove: %a@." pp_pkg (p,univ)
) remove;
Util.Timer.stop timer3 ();
--
2.5.1
Attachment:
signature.asc
Description: signature