You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It appears that hipBLASLt depends upon Tensile. However, instead of recognizing this fact, the dependency is ignored by the documentation and is instead vendored.
Vendoring of dependencies creates untold headaches for distributors as the packager needs to:
identify the implicit dependency
sort out what version of the dependency the package expects
figure out how to furnish the dependency in a way that works with whatever bespoke mechanism the package has developed
continually maintain all of the above as the package and its dependency evolve
For this reason, vendoring of dependency is highly discouraged. If hipBLASLt depends upon Tensile then there is a proper way to do so: advertise the dependency in the readme, and discover it via the usual dependency discovery mechanisms.
Operating System
Any
CPU
All
GPU
Other
Other
this is a packaging issue and not hardware specific
Thanks for the clarification. Nevertheless, it would be appreciated if this project (and ROCm projects more broadly) would make less use of build-time fetching of dependencies as this greatly complicates packaging. Specifically, many packaging policies strictly prohibit fetching of further resources from the internet. The source distribution (e.g. git repository or source tarball) must include everything necessary to build the the package. Many distributions go even further than this, prohibiting usage of vendored dependencies entirely. This is generally out of concern for security, auditability, and maintainability.
If the dependency is tightly-coupled to hipBLASLt then consider turning it into a git submodule. If not then make it a proper dependency.
I understand the introduction of dependency-fetching logic is often made with the good intention of making users' lives easier, but it generally makes packagers' lives harder, not easier. If such logic is still desired for end-users then the package's installation documentation should clearly describe how such logic can be disable and how the dependencies can be furnished via traditional means.
Problem Description
It appears that
hipBLASLt
depends upon Tensile. However, instead of recognizing this fact, the dependency is ignored by the documentation and is instead vendored.Vendoring of dependencies creates untold headaches for distributors as the packager needs to:
For this reason, vendoring of dependency is highly discouraged. If
hipBLASLt
depends upon Tensile then there is a proper way to do so: advertise the dependency in the readme, and discover it via the usual dependency discovery mechanisms.Operating System
Any
CPU
All
GPU
Other
Other
this is a packaging issue and not hardware specific
ROCm Version
ROCm 6.2.3, ROCm 6.2.2, ROCm 6.2.1, ROCm 6.2.0, ROCm 6.1.2, ROCm 6.1.1, ROCm 6.1.0, ROCm 6.0.2
ROCm Component
hipBLASLt
Steps to Reproduce
No response
(Optional for Linux users) Output of /opt/rocm/bin/rocminfo --support
No response
Additional Information
No response
The text was updated successfully, but these errors were encountered: