[Bug 820544] Review Request: libguac-client-rdp - RDP support for guacd

[bugzilla@xxxxxxxxxx]

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

Michael Schwendt <mschwendt@xxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mschwendt@xxxxxxxxx

--- Comment #39 from Michael Schwendt <mschwendt@xxxxxxxxx> ---
> And that's correct, as if I install a 64 bits package I expect
> to pull in 64 bit dependencies. Please read from comment #4 of this bug.

No, not again. :-/

It's disappointing you've not even thought twice before disagreeing with me.

A src.rpm package is arch-independent (!), which means it is built on an
arbitrary build server using an arbitrary arch, and the single src.rpm is
published in a _single_ package repository.

You can easily see the result of your packaging mistake if you downloaded the
src.rpm of your own libguac-client-vnc package, for example:

http://dl.fedoraproject.org/pub/fedora/linux/updates/17/SRPMS/libguac-client-vnc-0.6.0-4.fc17.src.rpm

Note that's _the_ single SRPMS repo for all archs!

$ rpm -qpR libguac-client-vnc-0.6.0-4.fc17.src.rpm 
cairo-devel(x86-64)  
gnutls-devel(x86-64)  
libguac-devel(x86-64) = 0.6.0
libvncserver-devel(x86-64)  
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1

Ooops! This is completely wrong for i686. Package resolvers will fail trying to
download x86_64 packages which are not available for i686. One would first need
to rebuild the src.rpm, which is highly recommended anyway, because there might
be conditional (arch-dependent!) BuildRequires in the spec file, which only
become active build requirements if the src.rpm is built on the correct target
arch.


> > %post -p /sbin/ldconfig
> > 
> > %postun -p /sbin/ldconfig
>
> Yes, this is probably a leftover, I will remove it.

No, they are needed. How else would dlopen find the libs? Could it be that you
just got lost due to lack of comments in your package?


> https://bugzilla.redhat.com/show_bug.cgi?id=820543#c8

That comment is misguided, unfortunately. There is a major difference between
"hiding shared libs in a subdir of %_libdir" (and effectively hiding it from
the run-time linker) and "moving shared libs into a subdir of %_libdir plus
adding that subdir to the run-time linker's search path". Do you realize what
the limited gain is when you do that?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
package-review mailing list
package-review@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/package-review