Re: Announcing the availability of first Qt 3.3 packages
Dominique Devriese <dominique.devriese@student.kuleuven.ac.be> writes:
> Brian Nelson writes:
>
>>> qt3-dev-tools: a number of binaries ( note: architecture dependent,
>>> so you don't want them in an arch independent headers package ) for
>>> normal development with Qt
>
>> Who said we need a arch-indep headers package anyway? I don't know
>> of any other library packages in Debian that have one. Hell, I
>> co-maintain one, if not the, largest library package in Debian and
>> it doesn't have headers split into a separate package.
>
> It's not a requirement, but it's generally a good thing to do, to save
> buildd time for arch-dep packages. Please read the packaging policy
> if you need more information. I'm not going to criticise your
> packaging of ace here.
Buildd time is generally not something to concern yourself with, unless
you're talking about hours of buildd time. Buildding a -headers package
takes mere seconds.
The real advantage would be to reduce the usage of archive space. Since
the headers in Qt are about 400K compressed, you're saving 400K * 11, or
about 4.4M. Whether or not that's a enough to justify the effort of a
split is somewhat debatable.
>>> qt3-apps-dev: stuff you need when you're going to be doing special
>>> things with embedding Qt designer and stuff. Almost noone needs
>>> this.
>
>> "Special things"? What the hell are "special things"?
>
> As I said: embedding Qt designer and stuff.
>
>> And the package name in no way suggests any difference from
>> qt3-dev-tools.
>
> Then you should be complaining about the package name, not the fact
> that the package exists.
I'm doing both. What does embedding Qt designer mean? Is that
something that is useful to many people?
>>> Anyway, if you're going to be making claims like this, it would be
>>> a lot more useful if you could provide us with a proposal about how
>>> you would like to see the package split up, so we could consider
>>> this in a useful manner.
>
>> As I said before, I think most stuff should be moved into a single
>> -dev package. For a working example, see the packages at
>> http://bignachos.com/~nelson/debian .
>
>> <snip: some usage scenario's>
>
>> So ultimately we're talking about a 2M difference for a developers
>> and 600K for users or buildds, with the trade-off being far simpler
>> packages (8 packages vs. 23 or whatever the current number is)
>
> Try to think of some more usage scenario's.
OK, but first note that I do not consider my Qt packages release
quality. I created them because I was frustrated with the current Qt
packages and needed something that worked better for me for my work.
They serve more as a demo to show a much simpler packaging scheme works
just as well in most situations. They work for me, but I'm not
advocating uploading them to unstable as-is.
In particular, I don't know if removing the single-threaded library is
viable at this time--it would need to be discussed first.
> For example: you seem to propose to not split out the compat headers,
> I think this would be a very bad idea, since I rely on this in my qt
> development to make sure I'm not using obsolete qt
> headers.
This was discussed on debian-devel around the time the split was going
to be made. Several people agreed that there were superior alternate
ways to accomplish this without splitting out the obsolete headers, and
consequently breaking the compilation of many packages.
For instance, you could put #warning pragmas at the top of each obsolete
header so that the compiler spits out a warning when one is used.
One of the reasons I'm so ornery when it comes to the Debian Qt packages
is that much of this stuff was discussed before the split and there
seemed to be a consensus that there were a lot of problems with it, yet
it was done anyway without heeding any of the advice.
> For another thing, Qt assistant is not only a development tool either.
> Many Qt apps use it to display their documentation. You would require
> every user of such apps to install the entire development package.
Really? I was not aware of this. I don't think it would matter much
though since I doubt any users other than Qt developers are aware of the
assistant, and the documentation is in html format readable by any web
browser anyway.
> You also seem to ignore non-multithreaded use of the qt libraries,
> even though there are still applications depending on this.
Well, there are only 2 packages in Debian still using them (I filed bugs
to fix all of them)--one appears to have a dead upstream and the other
has a negligent maintainer.
As far as I'm aware, there are not any circumstances in which the
multi-threaded library can not be used in place of the single-threaded
library, so Debian really has no need for it.
I think the only concern here is maintaining compatibility with other
distributions, which in this case I'd guess that's a minor concern since
most other distributions are probably using the mt library as well.
> You seem to not want to support embedded cross-development, again
> without considering people who need this.
There is already a Qt/Embedded source package in the archive. Can that
be used in place of the qt3-dev-tools-embedded stuff?
> Summarizing: Qt is a very complex package, and there are good reasons
> for most, if not all split-ups.
I'm still unconvinced of that.
> If you want to help, it would imho be more useful to send Martin
> patches for some of the real problems, as he has already requested
> often.
I have in the past, but they've been rejected (because Ralf Nolden is a
stubborn flaming nitwit IMNSHO).
I have also been going through bug reports, since many are no longer
relevant, already fixed. etc.
>> with fewer bugs (no missing files).
>
> I don't see a correlation between the number of packages and the
> amount of misplaced or forgotten files. As long as the package is
> split into more than one package, there can be mistakes in the
> splitting I guess.
There have been a lot of problems in the past with Qt assistant being
unusable due to misplaced files. Also, there seems to be a few headers
that have gotten lost. These problems would be more rare if there
weren't so many splits happening.
--
You win again, gravity!
Reply to: