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