Hello Christian, Thank you for sharing your experience, yes indeed building profiles doesn't really fix the problem, they are just providing convenience for building in this case. Meanwhile, I continued with my experimentation on gloo by taking "curl" as an example, and managed to build rocm and cpu in the same src:gloo. See my on going efforts on src:gloo: https://salsa.debian.org/deeplearning-team/gloo/-/merge_requests/6/diffs
But if we can't resolve the conflict between libgloo-rocm-dev and libgloo-dev then this won't help for the pytorch case. I dont have the historical knowledge regarding why we decided to have rocm as separate src:gloo-rocm package (I understood the cuda case) so trying to keep behaviour as same as today so that is creating challenge on how to handle gloo/config.h as it has information like `GLOO_USE_ROCM` which should be 0 for cpu only version and 1 for rocm only version. I will dig a bit more on gloo side, if it is possible to resolve the conflict while keeping the behaviour the same, without too much hassle (like with alternatives etc.) . But it would be great if you or someone else shared the experience on such cases so I can act accordingly. Best Regards, Talha Christian Kastner <[email protected]>, 14 Mar 2026 Cmt, 08:37 tarihinde şunu yazdı: > Hi Talha, > > On 2026-03-13 12:13, Talha Can Havadar wrote: > > I also have questions regarding the need of fork for ROCm. Why > > we are not using build profiles to build for rocm. I started > > experimenting this and the only conlict I see so far due to gloo-rocm > > (again forked from src:gloo) I think we could apply the same build > > profile logic to there as well. I am working on a PoC to see if that > > works. If it works it will require changes in src:gloo as well. > > If, by this, you mean: > > (1) have one src:pytorch, with multiple build profiles > (2) build and upload the ROCm variant via such a profile, instead of > a source fork > > Then sadly I don't think this will work, because the autobuilder network > will not build with such profiles. Furthermore, this goes against the > general expectation that one can just do `apt-get source` and > `dpkg-buildpackage` to get the same binary result. > > I tried something similar for ggml [1] and ultimately had to drop this > again [2], for the above reasons. > > Best, > Christian > > [1]: https://lists.debian.org/debian-ai/2025/12/msg00083.html > [2]: https://lists.debian.org/debian-ai/2025/12/msg00097.html >
