but not for deb releases:
http://download.ceph.com/debian-17.2.3/pool/main/c/ceph/
https://4.chacra.ceph.com/r/ceph/wip-yuri4-testing-2022-09-27-1405/cee7690a0
a431bd223254670505200901fccbd16/ubuntu/jammy/flavors/default/pool/main/c/cep
h/
so something further apparently needs to be done to the deb repo build.
The hope was that, if anything about the build process ever evolved
(like, say, making the cephadm file a zipfile instead of a Python script
As noted above it "just worked" for the RPM version. I'm not sure how to start
debugging it... if you would be so kind to help us (me) start debugging it I'd
really appreciate it.
Well, it's the Jenkins build that creates and uploads the packages to
shaman, and then shaman builds the repos. I thought I had once verified
that a non-deb file could sit alongside the .debs, just like it does for
the rpms, but maybe something changed about how shaman builds/publishes
the repos since I determined that, or maybe I was just wrong. We'd need
to examine the flow and see where it drops out.
:)), this process would be immune to such changes. But we never
finished getting the documentation/recommended practice updated.
Please let us know how we can help with this as well.
One concern I have with the "extract cephadm from packages" approach, beyond
technical stuff like shebangs, is that the existing user workflow is not
distribution specific. The user could be on ubuntu, or fedora, or centos, etc
and follow the same flow. I wonder if we could also create a download URL
(redirect?) that as not distro specific?
That might be a better answer overall, rather than trying to piggyback
on the distro repo. But the distro repo is the initial install source
for everything else, even if the 'binary' is the same across distros.
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx
