https://bugzilla.redhat.com/show_bug.cgi?id=1403417 --- Comment #28 from Mukundan Ragavan <nonamedotc@xxxxxxxxx> --- (In reply to Michael Schwendt from comment #27) > > --> License file is installed as part of the gsequencer package. > > -devel package has versioned requires for the base packages. > > > > However, -devel-doc does not depend on -devel or the base package. > > As far as I can tell, -devel-doc should also have versioned requires. > > No. Preferably, -doc packages are kept free of superfluous dependencies, so > one can install a documentation package for evaluation purposes without > dragging in -devel packages and possible tons of deps. > > https://fedoraproject.org/wiki/Packaging: > LicensingGuidelines#Subpackage_Licensing > "If a subpackage is dependent ***(either implicitly or explicitly) *** ..." The "implicitly" part I had forgotten. So, from a license file standpoint, this is fine. However, to me, a -doc package, particularly -devel-doc having versioned requires certainly makes sense. > > > Generic: > > [?]: Large data in /usr/share should live in a noarch subpackage if package > > is arched. > > Note: Arch-ed rpms have a total of 10199040 bytes in /usr/share > > See: > > http://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Guidelines > > > > ---> you may want to consider if it's appropriate to move the html docs to -doc subpackage. I do not really have a preference. > > That's not what fedora-review is trying to point out here. > > The total size of files in arch-ed rpms it refers to is mostly because of > the files in the -devel-doc package. Making that one "noarch" would be the > obvious solution. > My comment stands regardless. Personally, I think having a separate doc package is often nice. But, that's for packager to decide and that's what I have indicated. Of course, -devel-doc and -doc (if Joel decides to include) can be made no-arch as well. > > > gsequencer.x86_64: W: devel-file-in-non-devel-package /usr/lib64/gsequencer/libgsequencer.so > > > > ---> This seems to be a symlink to a versioned library. > > The symlink is unimportant. Important is that these libs are stored in a > directory outside runtime linker's default search path. True. It's not a "true" devel file. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx