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

Re: BUG: libkdeprint_management.la missing in kdelibs4



Chris Cheney <ccheney@cheney.cx> writes:

> On Wed, Feb 05, 2003 at 07:27:54AM +0100, Ralf Nolden wrote:
>> Yes, there is. First of all, there are people using this stuff to develop 
>> applications with. If you give them all available headers you will end up 
>> having most apps accidentally using compatibility headers which will sooner 
>> or later be drawn away by Trolltech. The reason why the plugin-headers 
>> package is there is that if you build a package that derives from (mostly 
>> stlyes) plugins, you will get a linker error at the end. In this case the 
>> error will show up much earlier during the compile and upstream or the 
>> author/developer will know that he did something wrong - deriving from a 
>> plugin where he should have used the plugin interface.
>
> 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.

>> Most problems of the current Qt packages came up because the packagers are no 
>> developers.
>
> According to you, if developers were packagers the debs would be in even
> poorer shape since they apparently don't even read the documentation for
> the toolkit they are using... 8-)

Bullshit.  At least they'd be able to realize that their packages are
completely broken, which the current maintainer is apparently incapable
of.

>> One oddity left is that when I need libqt3-mt-dev I have to download a package
>> that to 99% consists of a static library of 10 Mb size. This is completely 
>> rediculous compared to what I want. I suggested packaging the libqt.a and 
>> libqt-mt.a into a libqt3-static-dev package but Martin still refuses "because 
>> the policy says to put it in the -dev package". 
>> 
>> I can't argue against stubbornness, I can just say that two weeks discussing 
>> about every single file in this package drives me nuts, especially if debian 
>> people never use what they package and thus will never gain any clue what to 
>> do with it best.
>
> 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).

-- 
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: pgppZdTHLFHrV.pgp
Description: PGP signature


Reply to: