[PyKDE] Re: PyQt as a statically compiled shared library...

[Truls A. Tangstad]

On Tue, Jun 14, 2005 at 10:43:25AM -0300, Jorge Godoy wrote:
> "Truls A. Tangstad" <kerfue+pykde at herocamp.org> writes:
> 
> > What we're aiming for now though is making installation easier for
> > users on different linux systems to install our software without
> > having to satisfy all dependencies manually.
> Why don't you adopt the LSB way and uses RPM, as you did with DEB
> packages?  It is the easiest way.  And with Apt for RPM you can have
> the same installation procedure in different Linux systems.
> 
> There are Apt repositories for all major distributions and you won't
> have to worry with another dependency on your site... 

So it's possible to create a single RPM usable on
Fedora/SuSE/Mandrake? What about non-rpm systems like
gentoo/slackware?

(I have no experience in packaging for non-debian systems)

> > My though (which might be naïve) is to compile statically linked
> > binaries of the libraries/programs we directly depend on and then
> > provide them together with our software, modifying
> > LD_LIBRARY_PATH/PYTHONPATH on startup. Is it possible to create a
> > qt.so (with friends) that is statically linked against all its
> > dependencies, or is it a nightmare of manual labour?
> 
> This is a bad approach, IMHO.  It wastes a lot of resources since
> the system won't be able to share already loaded libraries.  Besides
> that, the size of your programs will also get very big, making it
> harder to download...

Yes, I know the tradeoffs, but the most important thing is having an
easy install that works for all systems.

> > Is there another approach which might be better for getting a
> > no-brainer installation usable across linux distros of a pyqt
> > program?  (for example not requiring user to install pyqt first)
> 
> I'd use Apt with RPM.  And write the dependencies as generic as
> possible, aiming a larger base.  

One problem we would have is testing and specifying versions. One
distribution might be very up to date, and provide libraries of
version which we require, others might be too old, or even too new. If
we stuff everything required into one package, all we should end up
depending on is the libc/glibc (hopefully), but then again, we'd have
to package in everything except the kitchen sink...

-- 
Truls A. Tangstad - <kerfue+pykde at h e r o c a m p.org>