Bug 1123963 - 'make distcheck' fails trying to install _DATA files to an absolute path
Summary: 'make distcheck' fails trying to install _DATA files to an absolute path
Keywords:
Status: ASSIGNED
Alias: None
Product: Fedora
Classification: Fedora
Component: automake
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Patrik Novotný
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-28 18:17 UTC by Stephen Gallagher
Modified: 2019-08-31 19:45 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
Trivial reproducer (10.00 KB, application/gzip)
2014-07-28 18:17 UTC, Stephen Gallagher
no flags Details

Description Stephen Gallagher 2014-07-28 18:17:17 UTC
Created attachment 921887 [details]
Trivial reproducer

Description of problem:
When a dist_<path>_DATA variable is set in Makefile.am, 'make distcheck' will fail attempting to install the file(s) specified in that variable to the real filesystem instead of to a subdirectory of $dc_destdir.

Version-Release number of selected component (if applicable):
automake-1.14.1-4.fc21.noarch
autoconf-2.69-15.fc21.noarch

How reproducible:
Every time.

Steps to Reproduce:
1. Untar the trivial reproducer attached to this bug into an empty directory.
2. Run "autoreconf -if && ./configure"
3. Run "make distcheck"

Actual results:
...
 /usr/bin/mkdir -p '/usr/local/mystuff'
/usr/bin/mkdir: cannot create directory ‘/usr/local/mystuff’: Permission denied
Makefile:273: recipe for target 'install-dist_mystuffDATA' failed
make[2]: *** [install-dist_mystuffDATA] Error 1
...


Expected results:
The distcheck should complete successfully.

Additional info:
Changing
mystuffdir = /usr/local/mystuff
to
mystuffdir = $(prefix)/mystuff
and it will work.

The thing that's highly peculiar is that 'make install DESTDIR=`pwd`/chroot' works correctly and installs the file inside the DESTDIR. This is why I believe the issue is a bug in 'make distcheck' specifically.

Note: it is not always possible to replace the absolute path with the $(prefix) or other path variables. In the specific case that spawned this issue, we were attempting to get a path from a pkg-config variable, which is returned as an absolute path.

Comment 1 Pavel Raiskup 2014-07-29 06:35:32 UTC
Stephen, thanks for this bug-report.

(In reply to Stephen Gallagher from comment #0)
> Created attachment 921887 [details]
> Trivial reproducer

Easily reproducible, thanks.

> Description of problem:
> When a dist_<path>_DATA variable is set in Makefile.am, 'make distcheck'
> will fail attempting to install the file(s) specified in that variable to
> the real filesystem instead of to a subdirectory of $dc_destdir.
> [....]
> Additional info:
> Changing
> mystuffdir = /usr/local/mystuff
> to
> mystuffdir = $(prefix)/mystuff
> and it will work.
>
> The thing that's highly peculiar is that 'make install DESTDIR=`pwd`/chroot'
> works correctly and installs the file inside the DESTDIR. This is why I
> believe the issue is a bug in 'make distcheck' specifically.

Hmm, I see your point;  but this is tough bug-fix request, really.  What I
miss on this bugreport is hint how you think this could be fixed.

Once you specify absolute address (without reusing ${prefix} or others already
containing ${prefix}), you usually go the hacky-way -- as you want install
such files independently of --prefix, *always*.  And by distcheck, you want to
test this configuration (always).  I can expect that this _may_ be desired,
though I think rarely and we should rather avoid such situations.

Characteristics of "distcheck" target are:

  1. checks `make install` works
  2. checks `make install DESTDIR=/sth` works (DESTDIR is optional!)
  3. does *not* require root privileges by definition
  x. .. many other things of course ..

And, when you use absolute paths, it is really hard to guarantee that the
1. point will work without root privileges.  The $dc_destdir exist for the
purposes of 2. point.

> Note: it is not always possible to replace the absolute path with the
> $(prefix) or other path variables. In the specific case that spawned this
> issue, we were attempting to get a path from a pkg-config variable, which is
> returned as an absolute path.

More than fixing/workarounding this in automake, I think we should found way
how to do this properly in '*.pc' files.  To think about this, I would need
concrete problem.  Blindly, pkg-config could give you the part of path without
${prefix} and you could specify it in Makefile.am.

Pavel

Comment 2 Pavel Raiskup 2014-07-29 07:23:07 UTC
(In reply to Pavel Raiskup from comment #1)
> More than fixing/workarounding this in automake, I think we should found way
> how to do this properly in '*.pc' files.  To think about this, I would need
> concrete problem.  Blindly, pkg-config could give you the part of path
> without
> ${prefix} and you could specify it in Makefile.am.

Could be usable (man pkg-config):
 |  --define-variable=VARIABLENAME=VARIABLEVALUE
 |         This sets a global value for a variable, overriding the value in
 |         any  .pc  files. Most packages define the variable "prefix", for
 |         example, so you can say:
 |           $ pkg-config --print-errors --define-variable=prefix=/foo \
 |                        --variable=prefix glib-2.0
 |           /foo

Comment 3 Thomas Woerner 2014-07-29 12:21:58 UTC
Here are the pkg-config calls, we are using to get the default directories we have to install files to:

pkg-config systemd --variable=systemdsystemunitdir
pkg-config dbus-1 --variable=system_bus_services_dir

Adding the option --define-variable=prefix=/foo does not have an effect on these, because the paths are hard coded in the pc files:

/usr/share/pkgconfig/systemd.pc:systemdsystemunitdir=/usr/lib/systemd/system
/usr/lib64/pkgconfig/dbus-1.pc:system_bus_services_dir=/usr/share/dbus-1/system-services

There are no .pc files in /usr/share/pkgconfig and /usr/lib64/pkgconfig, that are using $prefix in any other variables.

Comment 4 Pavel Raiskup 2014-07-29 14:02:59 UTC
(In reply to Thomas Woerner from comment #3)
> Here are the pkg-config calls, we are using to get the default directories
> we have to install files to:
> 
> pkg-config systemd --variable=systemdsystemunitdir
> pkg-config dbus-1 --variable=system_bus_services_dir
>
> Adding the option --define-variable=prefix=/foo does not have an effect on
> these, because the paths are hard coded in the pc files:

One step forward would be to ask systemd/dbus guys to enhance '*.pc' files,
IMO.  The problem is, that such fixes are not going to happen immediately but
making Makefile.am's should be portable enough *now*.

It is really ugly, but you can use 'PKG_CHECK_VAR' in configure.ac for both
'prefix' & 'systemdsystemunitdir' and substract the prefix from the later one.
The result you may AC_SUBST([mystuffdir]) according to example in question.

> /usr/share/pkgconfig/systemd.pc:systemdsystemunitdir=/usr/lib/systemd/system
> /usr/lib64/pkgconfig/dbus-1.pc:system_bus_services_dir=/usr/share/dbus-1/
> system-services
> 
> There are no .pc files in /usr/share/pkgconfig and /usr/lib64/pkgconfig,
> that are using $prefix in any other variables.

There are many, just grep for '${prefix}'.

Comment 5 Fedora End Of Life 2015-11-04 15:16:50 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 6 Pavel Raiskup 2015-11-05 06:35:16 UTC
I keep this open because I believe that it would be useful to improve
automake & pkg-config cooperation.

Random ideas:
* what if we had PKG_CHECK_VAR_CONFIGURE in pkg-config.  That macro
  would call $PKG_CONFIG with --variable=VAR=VALUE for all variables
  specified in $ac_subst_vars.

* teach pkg-config how to return "raw" (not expanded) variables defined in
  '*.pc' files.  Thus something like this:
  $ pkg-config systemd --raw-variable=systemdsystemunitdir
  ${prefix}/lib/systemd/system

Comment 7 Pavel Raiskup 2017-01-14 18:59:02 UTC
FTR, the command:

$ pkg-config systemd --variable=prefix='$(prefix)' ...

could have interesting effect, because then pkgconfig doesn't expand
'$(prefix)' string (it only expands constants/macros? specified with curly
brackets).  That means that _make_ expands $(prefix), which is nice thing.

Still, the *.pc files would have to use constants/macros consistently,
similarly to how we use %_*dir macros in spec files.

Comment 8 Pavel Raiskup 2017-01-14 19:25:00 UTC
Also FTR, theres DISTCHECK_CONFIGURE_FLAGS Automake's variable (can be used
to specify non-standard install locations only for distcheck time).


Note You need to log in before you can comment on or make changes to this bug.