I'm curious abotu why econf uses

"${EPREFIX}"/var/lib

for the default value of localstatedir, when the GNU coding standards
[1] and autoconf site default examples [2] both suggest

$(prefix)/var

Not that it's a big deal to add

src_configure()
{
econf --localstatedir="${EPREFIX}"/var
}

to an ebuild, but the missmatch is odd. I did some digging through
the history of both Portage and PMS, but didn't find anything clear.
PMS has had that value as the default since

commit a686e410fd4d20f1d67b1c991936de78379d00c1
Author: Stephen Bennett <spb@gentoo.org>
Date: Tue Mar 6 18:44:21 2007 +0000

Add build commands section based on pioto's patch. Add a TODO
command using the fixme package, and change todiscuss to use this
too. Possibly other misc changes.

which is not very informative on it's own. Portage has had the value
since

commit d9fc4acc572c6647a4f27b838d35d27d805d190e
Author: Jason Stubbs <jstubbs@gentoo.org>
Date: Sun Aug 28 08:37:44 2005 +0000

Migration (without history) of the current stable line to subversion.

Also not very helpful.

Anyhow, there is obviously a good deal of history here. Looking
through the ebuilds of packages on my system that do have something in
`/var/lib`, it looks like they either don't use autoconf
(e.g. sys-apps/portage), hardcode the path (i.e. avoid using
localstatedir, e.g. app-admin/eselect and app-crypt/mit-krb5) or
override the value in their own ebuilds (e.g. x11-base/xorg-server)

$ equery belongs -n /var/lib | while read LINE; do
ATOM="${LINE%% *}";
grep -c localstatedir "/usr/portage/$ATOM/"*.ebuild; done

Is this one of those things that's too baked in to be worth changing,
or is this just too peripheral to have bothered anyone else?

Thanks,
Trevor

[1]: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
[2]: http://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Site-Defaults.html

--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

On Friday 27 January 2012 16:21:21 W. Trevor King wrote:
> I'm curious abotu why econf uses
>
> "${EPREFIX}"/var/lib

my understanding is that from our sampling of packages over time, it seemed
more common for upstream to expect this to be a path where they would dump
state into. so if we used /var, packages would use /var/foo/ to store their
crap which really belongs in /var/lib/foo/.

either default is a crap one, so we went with the default that requires less
ebuilds to specify --localstatedir themselves. and at this point, it's not
really possible to change the behavior with EAPI, and trying to change it in a
newer EAPI violates the principle of least surprise.
-mike

>>>>> On Fri, 27 Jan 2012, W. Trevor King wrote:

> I'm curious abotu why econf uses

> "${EPREFIX}"/var/lib

> for the default value of localstatedir, when the GNU coding
> standards [1] and autoconf site default examples [2] both suggest

> $(prefix)/var

Right, and their $(prefix) defaults to /usr/local whereas ours
defaults to /usr. So the default localstatedir would be /usr/local/var
or /usr/var, respectively. While the former may make some sense, the
latter doesn't (and it violates the FHS).

> Not that it's a big deal to add

> src_configure()
> {
> econf --localstatedir="${EPREFIX}"/var
> }

> to an ebuild, but the missmatch is odd. [...]

That's not the same, the equivalent of $(prefix)/var is not
"${EPREFIX}"/var but "${EPREFIX}"/usr/var.

> [1]: http://www.gnu.org/prep/standards/html_node/Directory-Variables.html
> [2]: http://www.gnu.org/software/autoconf/manual/autoconf-2.63/html_node/Site-Defaults.html