On Thursday, May 18, 2023 4:58:30 PM EDT Kaleb Keithley wrote: > On Thu, May 18, 2023 at 9:57 AM John Mulligan <phlogistonjohn@xxxxxxxxxxxxx> > wrote: > > Unfortunately, I don't think this RPM derived cephadm is appropriate for > > general uses. RPM mangles the shebang line to something RH-distro specific > > so > > That's not entirely accurate. > > Packaging guidelines these days say that the python shebang should be > /usr/bin/python3. I believe that's true even for Debian and Ubuntu. > Agreed! > Some developers think it's smart to use #! /usr/bin/env python. In gluster > we had a mix of that and some #! /usr/bin/python or #! /usr/bin/python2 > shebangs. These were all changed to #! /usr/bin/python3. (Obviously on old > distros like RHEL7 it needs to be /usr/bin/python2 and in gluster we added > some sed magic to the glusterfs.spec to fix them at build time. Before its > EOL, RHEL7 was one of the last major distros still using python2.) > > On Fedora, RHEL, and SUSE, rpmbuild will whine about incorrect shebangs > during the build. It may even change them, I don't remember at this point. > IIRC, if it changes them, it changes them to /usr/bin/python3. Interesting.... when I wrote that I had just looked at a non-zipapp version of cephadm that was extracted from the RPM and it had a weird "system python" shebang (`/usr/libexec/platform-python -s`) see: `https://download.ceph.com/rpm-17.2.6/el8/noarch/ and download the `cephadm` the system extracted there. I was worried, but had not confirmed that rpmbuild was still doing that. I should probably get access to a proper main/reef build and see what the result is before saying more on this. :-) > > > this `cephadm` wouldn't work properly on distros like debian, ubuntu, etc. > > If all the shebangs are #! /usr/bin/python3 — either in the source to start > with, or changed by the rpmbuild — they work on Debian and Ubuntu just > fine. Or they should. If they don't, there's a different problem. > OK, that's good news. With the new zipapp compilation we have the ability to force the shebang to be something we explicitly set (like "/usr/bin/python3"). As of this moment it takes whatever shebang is default for python's zipapp module & function. > If cephadm is a separate package (for some definition of package) I have to > wonder why you're *not* working on adding them to Fedora and CentOS Storage > SIG, where Ceph and several related packages are already being packaged for > wide consumption. cephadm is part of the packages. For RPM it is one of the many sub-packages in ceph.spec.in. For another example, see the same dir linked above and the file `cephadm-17.2.6-0.el8.noarch.rpm`. That's probably the "best" way to get it on one's system. However, there's been a long standing workflow that one can aqucuire a "standalone" cephadm and bootstrap using that. See https://docs.ceph.com/en/pacific/cephadm/install/#install-cephadm and the curl based installation section. This is a workflow that is currently broken on "main" and "reef" and we're trying to replace/replicate. For exactly what systems and workflows we expect to use the curl based workflow, I'm not clear on but the idea may be to support other distros that have docker/podman support (because containers!). But I haven't been working on cephadm long enough to know - perhaps Adam will chime in here. :-) _______________________________________________ Dev mailing list -- dev@xxxxxxx To unsubscribe send an email to dev-leave@xxxxxxx
