Listing files twice and %lang behavior
Panu Matilainen
pmatilai at redhat.com
Thu Nov 26 07:15:40 UTC 2020
On 11/25/20 11:16 PM, Miro Hrončok wrote:
> Hello RPM list.
>
> I've recently discovered a little quirk and would like to know what is
> the proper behavior and whether we can make it so if there is none.
>
>
> For many times, I have used an equivalent of this:
>
> %files
> /xxx/foo/
> %lang(de) /xxx/foo/locale/de/LC_MESSAGES/foo.mo
> %lang(es) /xxx/foo/locale/es/LC_MESSAGES/foo.mo
>
> It gives a warning:
>
> warning: File listed twice: /xxx/foo/locale/de/LC_MESSAGES/foo.mo
> warning: File listed twice: /xxx/foo/locale/es/LC_MESSAGES/foo.mo
>
> But achieves the goal I need:
>
> 1) I don't have to carefully expand the directory structure of /xxx/foo/
> and %dir-dance around the .mo files.
> 2) The files end up being marked as %lang at the end.
>
>
> However, it seems that it is not always the case. I have a spec file at
>
> https://src.fedoraproject.org/fork/churchyard/rpms/mu/blob/rpm-list-reporducer/f/mu.spec
>
>
> That produces a list of files of this sort (hidden in
> %{pyproject_files}, but the file is cat'ed in %check for easier
> inspection).
>
> The file list contains:
>
> ...
> %lang(de)
> /usr/lib/python3.9/site-packages/mu/locale/de_DE/LC_MESSAGES/mu.mo
> ...
> /usr/lib/python3.9/site-packages/mu/
>
> The warnings happen:
>
> warning: File listed twice:
> /usr/lib/python3.9/site-packages/mu/locale/de_DE/LC_MESSAGES/mu.mo
> ...
>
> But the files are not marked as %lang:
>
> $ rpm -q --qf "[%-36{FILENAMES} %{FILELANGS}\n]" -p
> mu-1.0.3-6.fc34.noarch.rpm
> ...
> /usr/lib/python3.9/site-packages/mu/locale/de_DE/LC_MESSAGES/mu.mo
> ...
>
> https://koji.fedoraproject.org/koji/taskinfo?taskID=56256059
>
> I have not yet figured out when this happens. The order in %files
> apparently makes no difference.
>
> Is this one of the "it only works by accident" cases? And if so, can we
> maybe support it? it is really convenient.
Didn't yet look at the details of this case, but inconsistent behavior
tends to suggest a bug no matter which way you look at it.
Overall this is a specific case of
https://github.com/rpm-software-management/rpm/issues/336 - quoting
myself from there:
This is quite a common pattern in packaging where you have a package
owned "top" directory and then you'd want that one (or two...)
file/directory inside that to differ from the defaults. Whether for file
ownership / permission bits or virtual attributes. Not specific to %doc
or %license at all.
So it's a common packaging scheme that we should properly support. So
far, nobody has turned up with patches though...
- Panu -
> Thanks.
More information about the Rpm-list
mailing list