Relocate example binaries in binary packages

[jamiesnape]

Basically everything goes into /opt/drake/share/drake/examples/<example_directory> at present.

A preferable situation (since share is conventionally for platform independent files) would be binaries in /opt/drake/lib[/x86_64-linux-gnu]/drake/examples/<example_directory> for binaries, /opt/drake/share/drake/examples/<example_directory> for data (unchanged), and /opt/drake/share/doc/drake/examples/<example_directory> for licenses.

Alternative proposal would be everything except licenses to /opt/drake/lib[/x86_64-linux-gnu]/drake, with licenses joining all the other licenses below /opt/drake/share/doc.

Relates #12783.

[jamiesnape]

Note in Debian packaging terms, examples typically refers to source code examples, so our compiled examples do trigger warnings, but those are trivial to squash. Also, we have specific reasons for not throwing the binaries into /opt/drake/bin (mostly because we may have filename conflicts without the directory tree).

[jwnimmer-tri]

In theory, I would love to follow the FHS and keep "share" as platform-independent only, with the binaries in "lib". However, our use of data resources (and resource finding) does not distinguish whether the resource being sought is platform independent or not. If I want to call drake::FindResource on drake/common/resource_tool, that still needs to work. Shuffling around the installation paths to placate the Debian linter does not seem to be very valuable, given the development effort and user distress that it will cause. Is there any practical downside to diverging from the standard? We are already in /opt/drake all by our lonesome, it doesn't seem like it should matter what paths we choose?

[jamiesnape]

resource_tool is not under examples, surely? No linter placating, we already suppress several thousand complaints and I would make the same comment for the Mac packages. All our other licenses are under share/doc, so seems logical enough the others should be there, but if it is too much churn, it is really not that important.

[jwnimmer-tri]

I have no objection to reorganizing where the license texts end up.

I think my statement still applies to moving the example binaries, though. The example binaries can be sensible FindResource targets. Is there any tangible benefit to changing the installation paths of our programs? Is there any practical downside to leaving things alone (and so diverging from the "platform independent share" standard)?

[jamiesnape]

Just to summarize Slack here: data and binaries need to stay in the same tree for resource finding to work; moving everything to lib/<arch> may be helpful if/when we support multiple architectures; data in lib/<arch> may be as confusing as binaries in share, so probably not a big win there.

Save for the license fix up, assuming it is easy, probably should send this issue to the backlog or close it.

[jamiesnape]

#4224 (comment) is probably the future, so let's just close this for now.

[jwnimmer-tri]

... let's just close this for now.