Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

compat Go subpackages #48

Open
ingvagabund opened this issue Apr 11, 2018 · 2 comments
Open

compat Go subpackages #48

ingvagabund opened this issue Apr 11, 2018 · 2 comments

Comments

@ingvagabund
Copy link
Contributor

ingvagabund commented Apr 11, 2018

List of packages with compate subpackages:

  • golang-github-bradfitz-gomemcache
  • TBD

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
Copy link

nim-nim commented Nov 7, 2018

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
Copy link

nim-nim commented Nov 9, 2018

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants