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). -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
