https://bugzilla.redhat.com/show_bug.cgi?id=1403417 --- Comment #29 from Michael Schwendt <bugs.michael@xxxxxxx> --- > It's not a "true" devel file. That's much too vague. This review item is about avoiding a conflict between multiple non-versioned runtime libs with the same name. It would not be possible to install multiple "libgsequencer.so" at the same time, if all were installed into runtime linker's search path. Also, it *could* be a devel file and still be stored in the base package instead of a -devel package. Notice in build.log that gsequencer links with libgsequencer.so. So, what is it? An ordinary runtime lib? A plugin dlopen()ed from a subdir? Apparently not: $ gsequencer gsequencer: error while loading shared libraries: libgsequencer.so.0: cannot open shared object file: No such file or directory $ rpm -q gsequencer gsequencer-0.7.122.6-1.fc25.x86_64 $ rpm -qR gsequencer|grep gseq libgsequencer.so.0()(64bit) > [x]: Package functions as described. Not yet. > However, to me, a -doc package, particularly -devel-doc having > versioned requires certainly makes sense. What would be the rationale? That someone displaying the documentation would be forced to install a specific -devel package and all its [likely not fully versioned] deps even if only skimming over the API and its docs? Uhm. Note that the -devel-doc subpackage would be arch-specific but not multilib, and therefore you would be unable to follow https://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package because the base package dep could not be arch-specific. > Of course, -devel-doc and -doc (if Joel decides to include) can be > made no-arch as well. Making _large_ arch-independent data packages noarch is the whole point of that recommendation made by the fedora-review tool. It's less that many people share /usr/share over the network, it's more that in the repos, a single # dnf list \*-devel-doc|grep noarch|wc -l 13 # dnf list \*-devel-doc|tail -n +3 |grep -v noarch|wc -l 4 -- 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