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.
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
(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
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.
(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}'.
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.
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
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.
Also FTR, theres DISTCHECK_CONFIGURE_FLAGS Automake's variable (can be used to specify non-standard install locations only for distcheck time).
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
According to the low priority of this request and as it did not bother any user for years, I am closing this tracker. If you think this issue should be handled and investigated, feel free to reopen it.