Samba 3 has been discontinued since Q1/2015. So I think it's time
to just wipe it from the pkgs. FuseSMB is pretty much abandoned,
upstream does not exist and it's also not as useful as it used to
be anyways.
We only refer to openjdk by passing `--server_javabase="${runJdk}"` to
the `bazel` executable.
By passing jdk11_headless instead of jdk11, we cut bazels runtime
closure from 1.6 GiB to 1.1 GiB.
Next had a few issues with its packaging:
* the platform port was exposed in all-packages
And this is not useful for outside users.
It's now a local attribute in the next package.
* the platform port wasn't wrapped correctly
It appears that the lisp core was being wrapped,
when instead the actual gtk application that's
called within the lisp core had to be wrapped.
* codestyle/indentation
From looking at
* https://hydra.nixos.org/build/107447356
it appears the subtest fails at this exact step.
OCR in the testing driver has been notoriously
flaky, so let's just match alice's user description.
This does have the downside of not verifying the
appearence of other user cards, which was an
issue with the greeter in the past.
This cuts down the dependency tree on some rust builds where a crate not
just exposes a binary but also a library. `$out/lib` contained a bunch
of extra support files that among other information carry linker flags
(including the full path to link-time dependencies). Worst case this led
to some binary outputs depending on the full build closure of rust
crates.
Moving all the `$out/lib` files to `$lib/lib` solves this nicely.
`lib` might be a bit weird here as they are most of the time just rlib
files (rust libraries). Those are essential only required during
compilation but they can also be shared objects (like with traditional
C-style packages). Which is why I went with `lib` for the new output.
One of the caveats we are running into here is that we do not (always)
know ahead of time of a crate produces just a library or just a binary.
Cargo allows for some ambiguity regarding whether or not a crate
provides one, two, … binaries and libraries as it's outputs. Ideally we
would be able to rely on the `crateType` entirely but so far that isn't
the case. More work on that area might show how difficult that actually
is.
