Merge lp:~mir-team/mir/client-doesnt-really-need-to-depend-on-drivers into lp:mir

[Chris Halse Rogers]

Drop libmirclient8 dependency on client-platform drivers.

Similar to libX11, which doesn't depend on an X11 server.

This dependency is satisfied by other parts of the stack; the desktop-next and touch
seeds.

We're again in the situation where the mesa drivers and update-alternatives are breaking the vivid touch images.

While the *-platform-loading branches will fix the OMG EVERYTHING'S ON FIRE problem they'll still leave us with a whole bunch of unnecessary mesa on the touch images.

[PS Jenkins bot (ps-jenkins)]

PASSED: Continuous integration, rev:2224
http://jenkins.qa.ubuntu.com/job/mir-ci/2654/
Executed test runs:
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/860
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-clang-vivid-amd64-build/860
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-vivid-touch/822
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/651
        deb: http://jenkins.qa.ubuntu.com/job/mir-vivid-amd64-ci/651/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/822
        deb: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-builder-vivid-armhf/822/artifact/work/output/*zip*/output.zip
    SUCCESS: http://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/3939
    SUCCESS: http://s-jenkins.ubuntu-ci:8080/job/touch-flash-device/17094

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/mir-ci/2654/rebuild

review: Approve (continuous-integration)

[Daniel van Vugt (vanvugt)]

I'm not comfortable just relying on the desktop-next & touch seeds to install all the required packages for Mir.

If some other distro copied or converted our control file they would then not have correct dependencies for a working Mir client.

I'd like to see a "recommends" at least for drivers. Or even better, a dependency on some more abstract "driver" metapackage. Because if you don't have a driver, Mir doesn't work. We should communicate that in our own dependencies.

review: Needs Fixing

[Daniel van Vugt (vanvugt)]

/recommend/ Needs Fixing, but it's not a blocker if other reviewers disagree.

[Oliver Grawert (ogra)]

since RAOF takes Xorg as example here, how about dropping this lib dependency and at the same time add a more top level metapackage (mir) like X has with the xorg package which keeps carrying this dep. we dont need t depend on this package in a seed but people wanting to install mir will have an easy way to do this.

[Alan Griffiths (alan-griffiths)]

> they'll still leave us with a whole bunch of unnecessary mesa on the touch images.

There are touch images running on mesa

[Robert Carr (robertcarr)]

This is correct. I'll give an example use case: you may only want the library installed in order to link against in which case you shouldn't need a client platform.

>> since RAOF takes Xorg as example here, how about dropping this lib dependency and at the same time >> add a more top level metapackage (mir) like X has with the xorg package which keeps carrying this dep

This makes sense to me...should we add them to our existing mir metapackage?

review: Needs Information

[Daniel van Vugt (vanvugt)]

That's one reason. Although Ubuntu build deps rarely achieve such nice minimalism :)

Still sounds like we have some options that are nicer than the proposal as it presently stands.

[Alexandros Frantzis (afrantzis)]

> since RAOF takes Xorg as example here, how about dropping this lib dependency
> and at the same time add a more top level metapackage (mir) like X has with
> the xorg package which keeps carrying this dep.

+1 for Oliver's suggestion.

review: Needs Fixing

[Alan Griffiths (alan-griffiths)]

> since RAOF takes Xorg as example here, how about dropping this lib dependency
> and at the same time add a more top level metapackage (mir) like X has with
> the xorg package which keeps carrying this dep. we dont need t depend on this
> package in a seed but people wanting to install mir will have an easy way to
> do this.

+1

review: Needs Fixing

[Chris Halse Rogers (raof)]

> since RAOF takes Xorg as example here, how about dropping this lib dependency
> and at the same time add a more top level metapackage (mir) like X has with
> the xorg package which keeps carrying this dep. we dont need t depend on this
> package in a seed but people wanting to install mir will have an easy way to
> do this.

We already have mir-graphics-drivers-desktop and mir-graphics-drivers-android for just this purpose; is there something insufficient with this?

-desktop might be poorly named; it's (currently) the mesa platform, but might expand in future.

In particular, at the moment it would *not* be safe to have a mir metapackage that Depends: on both -desktop and -android, as there's no guarantee the correct alternative will win. We could possibly get away with arch-specific dependencies, but there are actually some pretty far advanced drivers in mesa for ARM hardware, so mandating -android on armhf isn't ideal.

[Alan Griffiths (alan-griffiths)]

I don't know the best way to express a solution - all the options seem bad

review: Abstain

[Alexandros Frantzis (afrantzis)]

> In particular, at the moment it would *not* be safe to have a mir metapackage that
> Depends: on both -desktop and -android,

We can wait for server-platform-probing to land and fix this while adding a mir metapackage in one go. Alternatively we can fix this and add the mir metapackage a bit later. Hopefully, we will be done before the next release.

review: Approve

[Andreas Pokorny (andreas-pokorny)]

agreed, in any case this dependency is not needed.

review: Approve

[Alberto Aguirre (albaguirre)]

Yeah there's just no good way of describing which driver dependency you need since I don't see a way to truly describe platform specs (like arch).

I suppose the desktop-next and touch seeds do that to some extent but not ideal either.

"I'd like to see a "recommends" at least for drivers."

+1

review: Needs Fixing

[Robert Carr (robertcarr)]

I forgot what was happening here. It seems like there are enough opinions that I don't need to find out again.

review: Disapprove

[Robert Carr (robertcarr)]

Whoops meant to ABSTAIN!

review: Abstain

[Chris Halse Rogers (raof)]

> I'm not comfortable just relying on the desktop-next & touch seeds to install
> all the required packages for Mir.
>
> If some other distro copied or converted our control file they would then not
> have correct dependencies for a working Mir client.
>
> I'd like to see a "recommends" at least for drivers. Or even better, a
> dependency on some more abstract "driver" metapackage. Because if you don't
> have a driver, Mir doesn't work. We should communicate that in our own
> dependencies.

It's not technically possible to provide such a solution; any attempt to do so will trigger exactly the same problem, as at some point apt is going to need to pick *which* driver to satisfy the “mir-driver” dependency, and it has no way to pick correctly.

Also, it's not quite technically correct. There are purposes for which libmircilent is entirely usable without any platform drivers.

[Alberto Aguirre (albaguirre)]

Ok.

review: Approve

=== modified file 'debian/control'
--- debian/control	2015-01-14 08:52:38 +0000
+++ debian/control	2015-01-15 01:57:00 +0000
@@ -144,7 +144,6 @@
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${misc:Depends},
          ${shlibs:Depends},
-         mir-client-platform-mesa | mir-client-platform-android,
 Description: Display server for Ubuntu - client library
  Mir is a display server running on linux systems, with a focus on efficiency,
  robust operation and a well-defined driver model.