https://bugzilla.redhat.com/show_bug.cgi?id=1403417
--- Comment #31 from Joël Krähemann <jkraehem...@gmail.com> --- Hi (In reply to Michael Schwendt from comment #29) > > 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. > You are right it doesn't work anymore. However I have tested it and it was working for that package. The library is there and it is in a private location. I think you don't want that? I have read once that on RPM based systems no libraries are private. [jkraehemann@localhost ~]$ ls -lh /usr/lib64/gsequencer/libgsequencer.so* lrwxrwxrwx. 1 root root 22 23. Feb 18:22 /usr/lib64/gsequencer/libgsequencer.so -> libgsequencer.so.0.0.1 lrwxrwxrwx. 1 root root 22 23. Feb 18:22 /usr/lib64/gsequencer/libgsequencer.so.0 -> libgsequencer.so.0.0.1 -rwxr-xr-x. 1 root root 1.1M 23. Feb 18:22 /usr/lib64/gsequencer/libgsequencer.so.0.0.1 Note the private library contains an unstable API that might change. It is documented and contains mainly composite widgets really specific to gsequencer. It could be used as blue-print if wished. It contains the AgsXorgApplicationContext. docs/reference/libgsequencer/libgsequencer.xml is present. I could provide a patch to make libgsequencer.so* resident in default linker location. But then you might want to provide the header files of libgsequencer, too. > > > 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 bests, Joël -- 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@lists.fedoraproject.org To unsubscribe send an email to package-review-le...@lists.fedoraproject.org
