[Bug 1403417] Review Request: gsequencer - audio processing engine

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



https://bugzilla.redhat.com/show_bug.cgi?id=1403417



--- Comment #31 from Joël Krähemann <jkraehemann@xxxxxxxxx> ---
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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]