gofed / go-macros

Rpm mechanics for Go packaging
4 stars 7 forks source link

compat Go subpackages #48

Open ingvagabund opened 6 years ago

ingvagabund commented 6 years ago

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.

nim-nim commented 5 years ago

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.

nim-nim commented 5 years ago

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)

Would that help your use-case?