[Bug 2295820] Review Request: hipblaslt - ROCm general matrix operations beyond BLAS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=2295820



--- Comment #6 from Tim Flink <tflink@xxxxxxxxxx> ---
(In reply to Jeremy Newton from comment #3)
> So some more information from a ROCm developer, we were in a meeting that
> included Tom and me:
> 
> The bundled tensile is a fork, and is expected to diverge from tensile (if
> it hasn't already) and become a replacement for tensile in rocm (other libs
> are supposed to eventually call rocblaslt).
> I'd rather just move forward, and we can drop tensile later if need be.

Yeah, that's mostly what I had understood when I talked to trix about it.

> > How do we handle the "bundled" tensile ... I don't think that it needs to be added to the provides but I also don't know if there is anything preventing this from happening
> 
> A bundle is a bundle, you need to add it regardless. The provides is more of
> a flag. I believe the intention is if they a security issue or similar
> critical issue in the library, the maintainer can look for the provides to
> notify the other maintainer that there's a critical bug that needs fixing.
> This could also be a CVE, a license issue, a copyright issue, a legal issue,
> etc. Providing a version is pretty important too for tracking.
> 
> E.g. say library A has a CVE and package B bundles A, then it's easy to
> query for "provides: A" to see what packages need updating, which would be A
> and B.

Sure, bundled libs should be handled like bundled libs and there's a reason
that process exists but that's not my argument here. I don't think that the
Tensile in tensilelite _is_ a bundle in the sense that we care about for
packaging.

As near as I can tell, this package never installs the forked, bundled Tensile
- it just installs it in a source dir subdirectory, adds that subdirectory to
PATH and PYTHONPATH before doing the actual hipblaslt build where I think it's
used to generate the platform-specific kernels. The Fedora package doesn't even
provide Tensile which is why I don't think it needs to have a bundled provides
in the spec.

Even if there were a CVE in this bundled Tensile, it's never distributed in a
Fedora package - it just exists on builders for a short time before that disk
is reclaimed post-build. We can have a discussion about whether that's a good
practice or not but unless there's something I'm missing here, this package in
its current state isn't bundling Tensile.


-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are always notified about changes to this product and component
https://bugzilla.redhat.com/show_bug.cgi?id=2295820

Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202295820%23c6

-- 
_______________________________________________
package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite Conditions]     [KDE Users]

  Powered by Linux