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

[Truls A. Tangstad]

On Tue, Jun 14, 2005 at 11:15:47AM -0300, Jorge Godoy wrote:
> "Truls A. Tangstad" <kerfue+pykde at herocamp.org> writes:
> 
> > 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)
> 
> They can install RPM as well.  There's a package of it for Slackware, IIRC.
> They'll have to worry with dependencies, though.  And this is one of the
> reasons that LSB adopted one standard...

The only reason for creating the Frankenstein-bundle is to handle the
dependencies for the users, instead of letting them worry about it.

> > > 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.
> 
> I'd avoid using something like that, unless there's no other way to accomplish
> something that I really need to...  But you have your reasons, of course. 

I'd like to avoid it too, but mostly because it seems quite a bit of
work to create and we might not even end up with something that's
guaranteed to work on all distributions. The Frankenstein-solution is
very much considered a hack to help users not able to use our existing
packages.

> > 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...
> 
> This is true...  But then, again, how big are you willing to make it?  I still
> think that a dynamic package is better than a stactic one.  But that is just
> my opinion and I don't really know what you have there.  It might be worth...

Space isn't really a problem as long as it creates a userfriendly way
of running the software. We might end up with small system-optimized
debs/rpms on the website, tested against specific linux distributions
(as far as we have capacity), and a Frankenstein-release available on
DVD on request. This will atleast allow anyone to run the software on
their system without having to compile software or search for rpms.

I still haven't decided if the monolithic Frankenstein-release is
something we really want to do though, but it's one way that atleast
would make it possible to easily install the software.

A compromise we're considering is having detailed installation
instructions for most distributions/systems on our wiki, where we
direct them to rpms/source for dependencies and how to install. More
work for users, and quite abit of work keeping the instructions/links
up to date.

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