Boris Vinogradov posted on Tue, 27 Nov 2018 21:13:35 +0300 as excerpted:
> I use gentoo about 8 year. I already try to write ebuild for my package
> but I think it's difficult to everyone who do it in the first time.
>
> Because ebuild have strange short name for common portage variable such
> as {P}, {PV}, {PN} etc. Another developers use these modified variables
> with name and preffix MY, for example {MY_P}, {MY_PV}. I think it isn't
> readable because everyone who read and write ebuilds sometime may be
> foget their means.
>
> I propouse to use human readble variable names for portage variables,
> such as {PATH} instead {P}, {PACKAGE_N}/{PACKAGE_NAME} instead {PN},
> etc... Human isn't a computer who knowns evething point of
> https://devmanual.gentoo.org/ebuild-writing/variables/index.html and
> other portage internals.
>
> I think it's major for everyone gentoo developer because ebuild is face
> of portage system and main component of gentoo unique feature.
It's worth noting that ebuilds conform to a gentoo common standard called
Package Management Specification (PMS), which defines ebuild-critical
variable names such as {P}, {PV}, etc, and that there are package
managers other than portage which along with portage depend on ebuilds
conforming to this standard or they will fail to function correctly.
Updates to this standard are usually done via defining new EAPIs, with
EAPI=7 being the current latest (tho note that while all officially
approved APIs have been sequential numeric, EAPIs are specifically not
required to be numeric, a historic experimental EAPI was named 5-hdepend,
for instance). Ideas for a new EAPI are proposed and discussed,
generally with a preliminary approval by the Gentoo council before
implementation in portage (as the defined PM reference implementation),
after which a final council approval is required before the new EAPI is
allowed to be used in the Gentoo tree.
So to propose human-readable standard var names you'd need to propose the
change as part of a new EAPI and get it approved as such, but of course
the existing EAPIs would remain in use for some time, so developers would
continue to need to know the existing EAPI vars until they are fully
deprecated and all ebuilds containing them are removed from the tree.
And honestly I must say I'm a bit skeptical, in part because in the
decade and a half I've been a gentooer (user not dev) myself, I've not
seen this sort of proposal before, so I suspect most devs must get
comfortable with the existing short vars pretty quickly, and would resent
the "churn for no good reason" and consequent relearning a wholesale
switch to "human readable" would mean for them. So I doubt its chances
at approval... tho I wouldn't really mind being proven wrong on this
point if you're up for the longer term drive to approval it'd take,
because...
As for me personally, as another user, when I'm working on modifying
ebuilds and don't remember the specifics of a standard var or function, I
open the ebuild (5) manpage in another VT or terminal window, and use it
for reference.
Another alternative is the app-doc/pms "Gentoo Package Manager
Specification" package, which contains the specific standards definitions
along with a nicely printable quick-reference card listing which EAPIs
define what. I have that installed too, as I suspect most devs and
advanced users doing ebuild work do, tho as I mentioned I personally tend
to find the ebuild (5) manpage easier for a quick lookup, and only tend
to use PMS when I'm checking details not in the ebuild (5) manpage or I
need the specific wording of the agreed PMS standard.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
