[Fedora-packaging] Is this allowed? Files and libs duplicated in subpackages

[Michael Schwendt]

On Wed, 4 Sep 2013 07:47:55 -0700, Toshio Kuratomi wrote:

> https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#DuplicateFiles
> 

Embarrassing. :) I was so focused on rpmbuild's "file listed twice"
warning that I didn't find this section in the guidelines. And rpmbuild's
warning is only per subpackage. It doesn't warn, if a file is included in
multiple subpackages.

> So that would also be a packaging mistake.  It's been many years since this
> was last touched though.  IIRC, mschwendt raised the last issue with it so
> he may be best able to recall the justifications for this rule and whether
> the FPC should consider relaxing it.

Relaxing it would be bad.

I agree with the interest in including a small file (other than the
license file or small %doc files) in multiple subpackages. That's okay.
It doesn't cause any RPM file conflicts.

However, it boils down to: The packager must know what he/she is doing,
and particularly must be aware of the consequences. For example, if the
duplicate files result in duplicate Provides (e.g. for shared library
names), this may affect dependencies in non-obvious ways (e.g. pulling
in the wrong package because it happens to include a copy of the needed
lib but missing other run-time bits).


To build multiple -devel subpackages, which contain exactly the same
set of files, only adds confusion and doesn't add any value at all.

To build multiple subpackages, and in the base package include copies of
the files from those subpackages, doesn't make any sense. And it's
a pitfall. In bugzilla I've added a comment on the scenario where
you want to rename/replace a subpackage.


Originally, avoiding duplicate files in %files sections has been made a
checklist item, because of the risks and to have packagers verify
painstakingly which file belongs into which (sub)package. Not because
duplicated files are always a grave mistake, but because avoiding
packaging mistakes (accidents) leads to cleaner packages. Examples:
Splitting off a noarch -data subpackage is of no benefit, if the base
package includes the data files, too. Easy to fix, though. 
Splitting off individual plugin subpackages is one of the pitfalls, if
the base package contains copies of all plugins (just think about how to
recover from that).