citrain device-upgrade fails to install Mir

[Cemil Azizoglu]

Hey Rob -
this pastebin shows what happened
https://pastebin.canonical.com/122936/

it's weird cause libmirplatform5 got updated....but not libmirserver or anything else.
wonder if it's some sort of wonky packaging thing specific to mir ??
...anyway, might be worth it to let people know to verify what the output says is getting installed, if you zone out and just ignore the output you might get fooled into thinking your testing your new libs when in reality you're not.

br,kg

Robert Park
6:39 PM (22 hours ago)

to Kevin, me
Thanks for the log. Ok, I think I see what's happening here. The key
part is this:

libmirserver27:
  Installed: 0.9.0+15.04.20141125-0ubuntu1
  Candidate: 0.9.0+15.04.20141125-0ubuntu1
libmirserver28:
  Installed: (none)
  Candidate: 0.10.0+15.04.20150107.1-0ubuntu1

In older versions of the script, we used to scan the PPA contents and
install *everything* found in there. This was problematic because some
source packages (of which I think mir is actually one ;-) produce
conflicting binary packages. So a more delicate approach was
necessary, to only install certain parts of a silo, not necessarily
all of it. Instead, what we do now is a dist-upgrade with all other
sources disabled (so it means, only upgrade packages, and only from
the silo, it blocks updates coming from distro).

In this case the silo didn't have a new version of libmirserver27, so
libmirserver27 didn't get upgraded. What you really wanted to happen
was have libmirserver28 to be installed at all, which it wasn't. At
first guess I'd say there's something wrong with your dependencies, in
order for libmirserver28 to get pulled in, something that is already
installed will need to have a dependency on it. I checked your
debian/control and what it looks like to me is that the only package
depending on libmirserver28 is libmirserver-dev, and that wouldn't be
installed on the phone, so indeed it seems there's nothing depending
on libmirserver28 in order to pull it in during the upgrade.

I recommend creating a virtual binary package alias to the latest
package version (that means, create a new binary package stanza in
debian/control with an unversioned name like 'libmirserver' and have
it depend on libmirserver28). then get the seeds to point at
'libmirserver' instead of 'libmirserverXX' so that the new package
becomes part of the image. with that in place, upgrades should happen
more smoothly in this case. Or if that's problematic, at least
something somewhere that's already installed on the phone needs to
grow a dependency on 'libmirserver28'. Otherwise, you guys will have
to Just Know "when we bump the number in the package name, we have to
install it manually after using citrain tool."

This isn't even really something that the citrain script can control,
this is apt's own package upgrade logic we're dealing with here.

I'm not sure how you got through 27 versions without having this be a
problem until now, did you perhaps change the structure of your
packaging recently? ;-)

[Cemil Azizoglu (cemil-azizoglu)]

citrain tool worked fine when Mir 0.9 was released (end of Nov 2014). Not for Mir 0.10.

[kevin gunn (kgunn72)]

this got fixed at some point, but nothing active on the mir part

[kevin gunn (kgunn72)]

actuallly, suggested solution was that when you have a new dependency for a package, the citrain can't handle that yet