gramineproject
Packaging issues to be fixed in 1.2
- [ ]
-Ddcap=enabled: requires Intel's repo with additional dependencies - [ ] sed shebang to
#!/usr/bin/python3, because usingenvis broken for custom (non-distro) python installs (see #429) - [ ] consider separate packaging libratls verify libraries, maybe for other architectures (thread about arm64: https://groups.google.com/d/msgid/gramine-users/9f0bbc15-6e10-44e5-aada-6ea47c3423d9n%40googlegroups.com)
- [ ] missing dependency against
libprotobuf-c1
@woju What do you mean by
sed shebang?
When change the shebangs, we'll need some mechanism of controlling them when packaging for different distros. Most likely in packaging (not in our meson), because those are different on different distros, some packaging systems already do it by default: https://src.fedoraproject.org/rpms/redhat-rpm-config/blob/rawhide/f/brp-mangle-shebangs. When packaging to different distros, I shall check if other also need and/or support it or do we have to do it manually (hence sed).
@woju I see your point. Is it something that we want to do in the future, or do you want to see this change now?
If now, then what exactly should I do in https://github.com/gramineproject/gramine/pull/429?
@woju I see your point. Is it something that we want to do in the future, or do you want to see this change now?
This isn't either "now" or "in the future", this is something that I need to adjust whenever I package for another distro. We need to do it now (gsc+python image is also kinda distro, because it's different python), and will need do again when new distro with new convention arrives (e.g. BSD).
Basically, we need a knob, whether it's meson option or just a sed postprocessing in packaging scripts (most likely the latter).
If now, then what exactly should I do in https://github.com/gramineproject/gramine/pull/429?
We should do whatever is convenient for gsc. As long as GSC compiles from
source, I think it should be /usr/bin/python3 (as the PR does). If we
switched GSC to apt install gramine, then we would be in position to keep
the "most correct" shebang of /usr/bin/env python3 in the source and
postprocess it in debian/rules. But this is a big change, we can always do
that later, and for now I think it's OK to do /usr/bin/python3.
We should do whatever is convenient for gsc. As long as GSC compiles from source, I think it should be
/usr/bin/python3(as the PR does).
Why not an option to Meson when installing? We could keep the sources better this way and change the shebangs only on these weird Docker images.
Why not an option to Meson when installing? We could keep the sources better this way
Two reasons (one and a half). 1) That's not how people usually do it. Most of the time buildsystems don't concern themselves with this, it's done by packaging stacks, because the excpected shebang is defined by distro policy and the tool to adjust is supplied by either distro itself (vide fedora, linked above) or the distro packager is expected to do it him/herself under penalty of distro-specific QA tool failure.
So if we did it, it would be instant no-op in RPM, because this would be
undone when packaging (but if properly done, it shouldn't hurt either).
I guess we can agree that docker python image is a poor distro itself,
supplies no good tool so we need to adjust this ourselves for it. Given the
choices (meson or RUN sed -i -e ... somewhere in GSC dockerfiles), meson
seem like not a bad option. Also (this is the point of this issue task) I'll
have /usr/bin/python3 shebang in debs one way or another, to force the
system-wide interpreter (to avoid potential custom interpreters, and
explicitly so gsc can apt-get install gramine).
Given all of the above, 1b) it turns out there will be no (packaged) release
with env shebang, so what would be in git repo will not be what people
actually run. I disagree with the assessment that "sources will be better this
way".
and change the shebangs only on these weird Docker images.
I don't think we can do it only on "some" images, at least I don't want to maintain a heurestics for detecting "weird" Docker images. We'll do it for all the Docker images, right?
One possible option would be to have meson do find_program('python3') and use the full path of the found executable to process script files, foo.in -> foo style (configure_file or custom_target). It would be autodetected on the build system side, but the final path would be frozen into the installed files. This pacifies Fedora policy, and offers the ultimate escape hatch to builders in that the preferred path to python3 can be defined in a machine file.
If we switched GSC to
apt install gramine...
@woju We are not going to do this in any near future. GSC is very frequently used to test the latest changes or to test feature branches. So I don't see GSC doing a switch from "git-clone and build Gramine" to "use Gramine package".
@mkow What would be your stance? I'm asking because I'd like to unblock #429 asap, otherwise we have broken GSC Docker images based on default Python image.
I don't think we can do it only on "some" images, at least I don't want to maintain a heurestics for detecting "weird" Docker images. We'll do it for all the Docker images, right?
@woju: I mean on some installs. I.e. GSC would pass an additional option to Meson build saying "please hardcode /usr/bin/python3". You wouldn't need this outside of GSC. This way we'd constrain this only to GSC.
I want to have #!/usr/bin/python3 by default, because it's a sane default which works on all distros we currently support. In debs, we have dependencies against other debs (python3-*), not requirements.txt-style dependencies against pypi packages, so in deb the only correct way is to have full path /usr/bin/python3 (otherwise running gramine-sgx-sign for example in venv is likely to break). Same for RPM.
For other, unsupported distros like *BSD or NixOS, we can have meson option to override.
I'm not sure if I want to do find_program('python3'), because again, if someone has non-standard python3 in $PATH while configuring builddir, then instructions in quickstart.rst are wrong: instead of apt-get install python3-* you need python3 -m pip install, and then there are some details like protobuf which gets compiled.
A quick comment from Pawel (in priv):
Apparently the default for distribution-packaged programs is to use a hardcoded path. Try it:
file /usr/bin/* | grep Python | cut -d: -f1 | xargs head -1
