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
This kinda complicates automatic analysis cause the compat rpm does not contain any source code, just a symlink to a newly named package. We should not create a compat subpackage just because a devel subpackage got renamed. My original impression was a compat package ships source code from a different tarball which is fixed in a commit and no longer updated (up to security fixes and/or on have-to-have patches bases).
We need to revisit application of the compat subpackages. In general, avoid usage of it.
The text was updated successfully, but these errors were encountered:
It's very hard to avoid those because golang project naming is fuzzy, so a project will always argue the import pathes it uses are the correct ones (some projects even mis-reference their own import pathes in their own code)
So in first approximation, you need the compat packages to identify who uses the problem import paths.
Without those I've seen the same project being packaged multiple times because the persons doing the packaging were not aware of the correct project name.
So, given, current upstream state, we're stuck with those packages, and they need to have all the usual provides otherwise other packages can not use them.
So, can't remove the packages, can't remove the provides.
However I could generate an additional provide no one else uses, just to mark they are not real import paths but symlinks (just for the root, like golang-ipath has been done)
List of packages with compate subpackages:
This kinda complicates automatic analysis cause the compat rpm does not contain any source code, just a symlink to a newly named package. We should not create a compat subpackage just because a devel subpackage got renamed. My original impression was a compat package ships source code from a different tarball which is fixed in a commit and no longer updated (up to security fixes and/or on have-to-have patches bases).
We need to revisit application of the compat subpackages. In general, avoid usage of it.
The text was updated successfully, but these errors were encountered: