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

Re: BUG: libkdeprint_management.la missing in kdelibs4

Ralf Nolden <nolden@kde.org> writes:

> On Mittwoch, 5. Februar 2003 09:59, Brian Nelson wrote:
>> > So most upstream authors have no clue how to write apps in Qt and don't
>> > look at the vast amount of documentation that come with it?
>> No, it means that most upstream authors don't expect styles to be built
>> as plugins.  Trolltech's documentation does *not* say that deriving from
>> a plugin is wrong.  Debian and Mandrake (I think) are the only
>> distributions to build styles as plugins, so many upstream authors don't
>> even realize the problem.
>> Of course, there isn't a good reason that I know of to build styles as
>> plugins in any case, other than satisfying Martin's need to make the Qt
>> packages as complicated and difficult to work with as possible.
> No, I have to object here. styles should be, for the sake of the necessary 
> size limit, be configured as plugins. With qt3 being able to use KDE styles 
> as well (which are plugins, too), the user will only have one stlye that he 
> will use. Do you expect every user to load 600 k minimum of bloat just 
> because one author of a program got it wrong ? When I discover such a case 
> I'm contacting the author and in all cases that I met I got an immediately 
> fixed version uploaded that corrects the problem with the styles. This is the 
> way IMHO to deal with this issue.

Considering libqt is about 5.5 megs, an extra .5 meg doesn't seem so bad
to me considering the trouble it saves.  Besides, is anyone that uses Qt
apps, like KDE, seriously concerned about .5 meg of bloat?

> Martin is not guilty of making Qt complicated. It's upstream who is 
> responsible for most of the confusion (-mt and non-mt, style plugins etc. 
> etc. etc. without a clear guideline for packagers - because TT customers 
> build Qt themselves and don't care about packages on Linux)

Sure, but that doesn't mean Debian's Qt packages have to suffer as a
result of TT's vagueness.  Just put all the headers in one package,
package only the mt lib, build styles statically, and end the madness.

>> > Yes, Martin is correct about that being a violation of policy, most
>> > (all?) other libraries don't split their headers into a bunch of
>> > individual packages either, but ymmv.
>> Where in policy does it say that?  There's already a couple packages
>> that package their static libraries separately (octave2.0-staticlibs for
>> example).
> Good point. Please help elaborate this to convince Martin to package the 
> static libs that noone needs anyway into a separate package :-)

The only place I can find that mentions packaging static libraries in
the -dev package is libpkg-guide, and that documentation is by no means
authoritative.  I don't see why they should be included at all.  If some
third party vendor needs to link statically with Qt for whatever reason
(Opera?), they can compile the libs statically themselves.

My secret to happiness... is that I have a heart of a 12-year-old boy.
It's over here in a jar.  Would you like to see it?

Attachment: pgp3oWmC7WSto.pgp
Description: PGP signature

Reply to: