| Summary: | dev-util/idea-community should be renamed to dev-util/idea-community-bin | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | fee1-dead-beef |
| Component: | Current packages | Assignee: | Mike Pagano <mpagano> |
| Status: | RESOLVED INVALID | ||
| Severity: | enhancement | CC: | alicef, jstein, ulm |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
fee1-dead-beef
2020-12-14 08:59:26 UTC
The ebuild fetches* compiled binaries from jetbrains's website. we have no strict rule that -bin is mandatory for all binary packages. I would prefer such a rule, but there is none. (In reply to Jonas Stein from comment #2) > we have no strict rule that -bin is mandatory for all binary packages. > I would prefer such a rule, but there is none. The thing is, using a name without an indicator that it is a binary package discourages users from creating ebuilds that builds the package from source. I would prefer a package that builds it from source but if someone creates one, they are going to have to name it like idea-community-git or something. ulm, didn't you try to make some consistency rules for situations like these? This is all I could find: Binary packages Gentoo usually builds its packages from source. Exceptionally, a binary package can be provided instead (e.g., if upstream does not provide a source). Such packages should still follow normal naming conventions and do not need any special suffix. If a binary package is provided in addition to its open-source based equivalent, the name of the former should be suffixed with -bin if necessary for distinction. Examples are packages that are heavy on resources like CPU time or memory when being built from source. https://devmanual.gentoo.org/ebuild-writing/file-format/index.html#file-naming-rules I think the above applies it's not *technically* required. Thought let me add that it does make things more clear to just look at an package and know right away. I'll connect on alice on irc. (In reply to Joonas Niilola from comment #4) > ulm, didn't you try to make some consistency rules for situations like these? That's the policy quoted in commment #5. The package name shouldn't have a -bin suffix unless there's both a source-based and a binary package. (In reply to fee1-dead-beef from comment #3) > The thing is, using a name without an indicator that it is a binary package > discourages users from creating ebuilds that builds the package from source. > I would prefer a package that builds it from source but if someone creates > one, they are going to have to name it like idea-community-git or something. No. As soon as a source-based ebuild exists, the existing binary package would normally be removed. It can be kept if there are exceptional circumstances like a very long compile time; in which case it should indeed be renamed to -bin (but only then). (In reply to Ulrich Müller from comment #7) > (In reply to Joonas Niilola from comment #4) > > ulm, didn't you try to make some consistency rules for situations like these? > > That's the policy quoted in commment #5. The package name shouldn't have a > -bin suffix unless there's both a source-based and a binary package. > > (In reply to fee1-dead-beef from comment #3) > > The thing is, using a name without an indicator that it is a binary package > > discourages users from creating ebuilds that builds the package from source. > > I would prefer a package that builds it from source but if someone creates > > one, they are going to have to name it like idea-community-git or something. > > No. As soon as a source-based ebuild exists, the existing binary package > would normally be removed. It can be kept if there are exceptional > circumstances like a very long compile time; in which case it should indeed > be renamed to -bin (but only then). With that said... I'm going to close this bug. fee1-dead-beef (or anyone) feel free to open another bug challenging the policy if you think it doesn't make sense. If the policy get's changed, I'm happy to make the change to adhere to the new policy. The way I am reading Ulm's comments it would be a qa violation to make this change at this point. Just as a reference, link to policy discussion: https://archives.gentoo.org/gentoo-dev/message/8dadfbd3c15b6580abb84882e9115a47 |
