Summary: | dev-libs/capstone : split bindings into a separate ebuild | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Anton Bolshakov <anton.bugs> |
Component: | Current packages | Assignee: | Sergei Trofimovich (RETIRED) <slyfox> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Anton Bolshakov
2019-11-02 01:16:47 UTC
If the bindings are released as a part of the same source tarball I would prefer to keep it as a single package. Adding USE flags is not hard. That would ease bumping a package and keep library+bindings in sync as opposed to bump a bunch of packages. I'm not against adding more bindings support into existing ebuild. I think the keyword is community bindings See https://github.com/aquynh/capstone/blob/master/bindings/README There are around 15 additional bindings, they are all hosted by different authors Please reconsider (In reply to Anton Bolshakov from comment #2) > I think the keyword is community bindings > See https://github.com/aquynh/capstone/blob/master/bindings/README It does not help me to understand existing problem. > There are around 15 additional bindings, they are all hosted by different > authors > Please reconsider External packages maintained by their authors are standalone projects can go into their packages in gentoo. Why does it relate to canstone python (or other bundled) bindings that are part of capstone tarball? well, ok. It may be make sense to write 15 separate ebuilds for each binding. Let me be this way. |