[Scribus] best OS to keep up with scribus, gscript and inskcape dev...

[PLinnell]

On Tuesday 01 March 2005 16:13, Tariq Rashid wrote:
> although this may sound like an inappropriate question - its not.
>
> i am now starting to produce documents that will need to be as good
> as possible as they are for public consumption.
>
> i have always used mandrake (now 10.1) as my workstation as it has
> had quite up to date software ... but i am finding it a pain to
> keep up with inkscpape and scribus development.
>
Heh, its the same for developers. Inkscape 0.40 was *very* difficult 
to get working on Suse 9.x. Its much easier now however with updated 
support libs available.

> never mind the fact that mandrake, amongst other major distros,
> ship ghostscript 7.07!
>

No rpm distro AFAIK except for betas/cooker of Mandrake have anything 
newer than 7.07. The long standing reason is the lack of CUPS 
integration in GPL GS 8.x - now fixed and migrating into distros. For 
major distros upgrading to GS 8.x is complex and is comparable to 
going from GCC 2.9x to GCC 3.x. 

That said, installing a parallel version of Ghostscript 8.50 is not 
too difficult. I have provided very complete instructions on 
docs.scribus.net.. I've yet to receive complaints about a broken 
system from my hints. :)

On the other side Ghostscript as shipped by RedHat/Suse/Mandrake can 
be looked at as a: a fiendishly complex work of hackery or b: a 
marvel of integration via sed/perl/rpm macros. ;-)

Even someone like me who has been around PC 's before they were called 
PC can't but helped to be impressed to plug in a new USB printer in 
Suse and without any (interaction/dialogs/feed driver disk/reboot)  
have a fully configured and working printer automagically and 
recognized by the desktop apps.

And some people think the Linux desktop sucks...


> i wonder if a more "source" bases OS is a better idea to keep up
> with changes upstream, whilst keeping the local workstation
> integrated - ie if i update ghostscript i don't want CUPS printing
> to break, etc etc
>

See above. 
> do people use rolling (non-release) systems like gentoo? freebsd
> ports? netbsd pkgsrc? debian testing?
>
> the core question really is which distribution gets the upstream
> changes in a timely manner?
>


With respect to Scribus IMO, *the* most important issue is how Qt is 
both compiled e.g the ./configure switches, which are complex *and* 
the packaging, which often have a grab bag of patches.

I've cracked open the source packages for Qt packages of some of the 
major distros while we were hunting down a drag and drop bug in 
Scribus, which ended up being a Qt issue. Doing that,  I learned  
some about how Qt/KDE is built. 

My vote: Suse 

Their most current rpms:
 a: are compiled closely to the KDE developer recommendations 

b: also include patches and fixes which often get sent upstream to Qt. 
Suse employs a fair amount of KDE devels who do know their way around 
Qt. 

c: Suse usually is one of the first major distros to release updated 
KDE/Qt rpms when KDE announces a new version. There were Qt 3.3.4 
rpms available very shortly after it was announced and they were a 
painless upgrade without breakage.e.g.

rpm -Fvh ./qt*

done

d: I observe far fewer issues with Suse's Qt + Scribus than any other 
distro based on bug reports, the mailing list or my own usage.

Second choice would be RH/Fedora. They have do not have the same 
number of devels supporting Qt,  but their current packaging has 
removed all the ugliness of RH 8/9 days and its sane. Despite 
perception, there are RH/Fedora devels who do like KDE and many use 
it as their main desktop. 

FC-4 will be the first distro which will have  GCC 4 standard and  GCC 
4 is *far* more particular about c++ correctness, along with giving 
c++ apps a  performance kick. 

Where rpm/packaged distros win vs. source distros is maintaining 
multiple machines.

Its not difficult to make a buildroot for rebuilding SRPMs which can 
then be installed on other local workstations. The scribus spec files 
in both Fedora and Suse have been massaged carefully for a long time, 
so they should just work (TM). 

I don't know much about packaging Debs, so I can't comment. I'm not 
really sold on how Debian packages Qt, but that's my personal taste.

Using RPM is much easier than even a year ago. Apt-rpm is available 
for Suse/RH and others. Plus like the fedora-develrpm tools make 
building them much easier locally.

Just my personal thoughts, nothing meant to be official ;-)

Peter