Merge buildah

[FranklinYu]

https://packages.debian.org/sid/source/golang-github-containers-buildah

[AMDmi3]

Unfortunately we don't merge this naming pattern. go packages don't have canonical naming scheme so we'll have to manually maintain rules for each pattern of each package naming in order to merge them, which is not affordable. Additionally, it doesn't look like the url-based scheme is justified in this case.

[FranklinYu]

Sorry I didn’t quite get the first part. Sounds like we have a general policy for (against?) Go packages? Is it documented anywhere, or is there prior discussions I can refer to?

[AMDmi3]

Some policies are documented on report page https://repology.org/project/buildah/report

[FranklinYu]

Thanks, I found the part against Go packages. But I still don’t quite get the reason: does naming-scheme refer to how the packager name the Debian package (i.e. golang-github-containers-buildah)? I thought that packages are merged one by one anyway, even with Python or Perl. How would the lack of consistent naming scheme make the maintenance more difficult?

[AMDmi3]

does naming-scheme refer to how the packager name the Debian package

Yes.

I thought that packages are merged one by one anyway, even with Python or Perl.

No, module packages are processed with wildcard rules. Written once, these cover all existing and future module packages and do not require manual maintenance.

That's not possible with go - go modules do not even have canonical names. We should probably take URLs as these, but there's still no consistent normalization pattern across distros, and existing patterns cannot be converted to each other.

Example: https://repology.org/projects/?search=go%3A%25toml

[FranklinYu]

You mean, for other languages (Python and Perl) the wildcard rules can handle most packages, while this pattern cannot scale with Go modules? This is the concern of accepting Go merges?

Then maybe in this specific case (Buildah) there is another way to fix it: the Debian source package is the bad name golang-github-containers-buildah, but one of the binary package is simply buildah. Would that help us decreasing the number of manual merges required for some “(relatively) good” Go packages?

[AMDmi3]

You mean, for other languages (Python and Perl) the wildcard rules can handle most packages, while this pattern cannot scale with Go modules? This is the concern of accepting Go merges?

Yes.

Then maybe in this specific case (Buildah) there is another way to fix

Not really. Binary packages have their own name discrepancies and require more manual rules on their own.