RPM shows warning about including file twice when using %doc

[ignatenkobrain]

I think such construction

%files
/usr/share/foo
%doc /usr/share/foo/examples

should just mark examples directory as %doc and not warn about double-inclusion. I've tried to use %exclude but it just excludes thing completely.

Let me know if I can provide more details

[pmatilai]

I don't see how you'd get duplicate warnings in that scenario. An actual reproducer would help.

[ignatenkobrain]

# Generated by rust2rpm
%bcond_without check
%global debug_package %{nil}

%global crate scopeguard

Name:           rust-%{crate}
Version:        0.3.3
Release:        1%{?dist}
Summary:        RAII scope guard that will run a given closure when it goes out of scope

License:        MIT or ASL 2.0
URL:            https://crates.io/crates/scopeguard
Source0:        https://crates.io/api/v1/crates/%{crate}/%{version}/download#/%{crate}-%{version}.crate

ExclusiveArch:  %{rust_arches}

BuildRequires:  rust-packaging

%description
%{summary}.

%package        devel
Summary:        %{summary}
BuildArch:      noarch

%description    devel
A RAII scope guard that will run a given closure when it goes out of scope,
even if the code between panics (assuming unwinding panic).

Defines the macros `defer!` and `defer_on_unwind!`; the latter only runs
if the scope is extited through unwinding on panic.

This package contains library source intended for building other packages
which use %{crate} from crates.io.

%prep
%autosetup -n %{crate}-%{version} -p1
%cargo_prep

%build
%cargo_build

%install
%cargo_install

%if %{with check}
%check
%cargo_test
%endif

%files          devel
%license LICENSE-MIT LICENSE-APACHE
%doc README.rst
%{cargo_registry}/%{crate}-%{version}/
%doc %{cargo_registry}/%{crate}-%{version}/examples

%changelog
* Mon Oct 23 2017 Igor Gnatenko <[email protected]> - 0.3.3-1
- Update to 0.3.3

* Thu Jun 15 2017 Igor Gnatenko <[email protected]> - 0.3.2-1
- Initial package

from build.log:

warning: File listed twice: /usr/share/cargo/registry/scopeguard-0.3.3/examples
warning: File listed twice: /usr/share/cargo/registry/scopeguard-0.3.3/examples/readme.rs

[ignatenkobrain]

@pmatilai obviously I made typo, it is supposed to be %doc /usr/share/foo/examples...

[pmatilai]

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.

The warning is there to point out possible packaging bugs, so what's needed is a way to tell rpm what you actually mean here. One possibility is simply making the pattern legitimate and try to be more clever about the complaints, generally something like: if one entry is using defaults and the other has non-default values then just let the non-default win silently, but if both are using non-default values then both can't be right and a warning should be issued. And I suppose a warning should be issued for identical entries too - it might be entirely harmless but it's almost certainly a packaging mistake anyway.

[ignatenkobrain]

@pmatilai I think that would work in my case (I mean your proposal about non-default-vs-default values). Are you going to implement it yourself or should I? Is it only about comparing uids, filemodes and so or there are some other worms inside?

[pmatilai]

Working on this is not in my plans. But then (too) much of my work isn't exactly planned...

See the "Merge duplicate entries" code for the things that need comparing, figure out the right thing to do for each:

• if it can be meaningfully handled, just do so
• if it looks like a packaging bug, whine
• if the entries actually conflict (like differing ownership or permissions which can't be merged) then it should error out and not just warn

[torsava]

Thanks, @pmatilai for finding the duplicate! Indeed this has been problem for a while, as the pattern is quite common.
And as described in #2144 (comment), it's almost impossible to avoid. Is there a path forward?

[pmatilai]

Well, all it takes is somebody to sit down, apply reality to my outline above and code it up 😁

Lifting to Todo-stage in the project may also help - this appears a relatively straightforward case.

[torsava]

Well, all it takes is somebody to sit down, apply reality to my outline above and code it up grin

Lifting to Todo-stage in the project may also help - this appears a relatively straightforward case.

Sounds good! Anything I can do to get it to the TODO-stage? 😃

[pmatilai]

Already moved it there 😃