Project:Proxy Maintainers/User Guide/Style Guide

Proxy-maint follows QA and devmanual policies, and in addition to that, recommends some general styling guidelines. That is common within big projects who maintain a lot of packages. Rationale being common, consistent styling, and especially in proxy-maint project it makes ebuilds and files more readable which enables faster review times. Proxy-maint follows default skel syntax for ebuild and files.

Usually cosmetic issues are not a reason to reject your contribution, but if other QA issues are pointed out and asked to fix, you might be additionally asked to fix any cosmetic issues to honor our guidelines. Please work with us.

Avoid using single-char *DEPEND variable
Avoid using,   and such. Instead use any definitive word instead of 1 char. For example,  ,   are good.

Any 1-character *DEPEND should be reserved for internal portage usage. When such variable is introduced, we don't have to start updating multiple ebuilds, because we've done the preventive work already.

See Future EAPI how portage might start using such variables in future.

Clean, compact, readable
Minimize vertical whitespace:

Use:

Where line length doesn't exceed 100 chars. Remember indentation.

Descriptive text
We don't put dot at the end of descriptive texts like these:
 * field in an file
 * in

One empty line below EAPI= line
We try to follow the default skel format whenever possible. If in doubt, use

Or in emacs with ebuild-mode  to make an empty ebuild with correct structure. For those not using vim or emacs, provides documented skeleton file.

Plaintexting ${PN}
We like to plaintext ${PN} variable in SRC_URI and REPO_URI, because it's not a changeable variable and makes copy-pasting from your ebuild easier, or using external tools such as grep.

See also PG 0103, similar rationale applies here.

Sorting dependencies

 * 1) Unconditional deps, sorted alphabetically
 * 2) Conditional deps, sorted by USE flag, also alphabetically

Handling multi live/release ebuilds
Live ebuilds are not mandatory, but if you'd like to provide them, use structure such as this:


 * Use  instead of  . It's cleaner, simpler, shorter and proven to work with in every case (different package manager implementations for example).
 * Do not specify  inside "9999" block, as it breaks the   tool (PG 0105).
 * You can also use  for "pre-live" releases, like 1.2.9999, or -99999999 packages.