[Pcsclite-muscle] Incorrect use of Autoconf to expand variables in plaintext files

[Ludovic Rousseau]

Le sam. 4 déc. 2021 à 04:08, Kirill Elagin <kirelagin at gmail.com> a écrit :
>
> Hello,

Hello Kirill

> First, here is a concrete instance of this issue. In pcsclite 1.9.2
> `EnvironmentFile=` was added to the `etc/pcscd.service.in` file. If
> you look at a machine that has this (or newer) version installed, you
> will find in `/etc/systemd/system/pcscd.service` this line:
>
> ```
> EnvironmentFile=-${prefix}/etc/default/pcscd
> ```
>
> It results in the following error reported to the system journal:
>
> ```
> systemd[1]: /etc/systemd/system/pcscd.service:9: EnvironmentFile= path
> is not absolute, ignoring: ${prefix}/etc/default/pcscd
> ```
>
> The root cause is that `AC_CONFIG_FILES` is used, arguably somewhat
> incorrectly, to replace all kinds of variables in all kinds of files,
> while it is meant to only list makefiles. Quite often, this is not a
> problem, since those variables just get replaced by correct values and
> that’s it, however some variables do not get expanded fully, for
> example, the @sysconfdir@ variable used in `pcscd.service.in` is
> replaced with literal `${prefix}/etc` by default as can be seen above.

You are completely right.

I missed this problem because I use an explicit --sysconfdir=/etc so
the correct value was used
https://github.com/LudovicRousseau/PCSC/blob/master/c.sh#L7

The Debian package also uses (implicitly) --sysconfdir=/etc so
everything was working fine on my side.


May I ask what GNU/Linux or system do you use?

> In addition to that, pcsc-lite (ab)uses `AC_CONFIG_FILES` to replace
> variables in some other files too, however this does not cause
> problems since, as far as I can tell, all of those variables are of
> the kind that gets expanded fully – with one notable exception: the
> variables used in `src/libpcsclite.pc.in` are also not being expanded
> fully, so they remain in the generated file, however, luckily, .pc
> files allow references to other variables defined in the same file and
> due to a convenient coincidence the names of the variables used by
> `./configure` and defined in the `libpcsclite.pc` match. I don’t know,
> I mean, this still sounds a little fragile to me and I think it would
> be better to switch to some more robust solution.

libpcsclite.pc is not (yet) broken so I do not plan to change anything here.

Thanks for the bug report and the patch.

Regards,

-- 
 Dr. Ludovic Rousseau