[Releasing] [Development] Qt 5.7.0 beta snapshot available - gtk 3 and packaging on RHEL 6

Lisandro Damián Nicanor Pérez Meyer perezmeyer at gmail.com
Mon Apr 11 18:37:03 CEST 2016


On Monday 11 April 2016 16:50:18 Frederik Gladhorn wrote:
> Hello all,
[snip] 
> For Qt 5.7, the options seem to be:
> 1.) ignore the problem and ship Qt packages in the installer without gtk
> theme 2.) revert the patch to have the gtk2 theme for one release longer
> and only have gtk3 with Qt 5.8
> 3.) package on rhel 7, but I'm told, we're already too late in the cycle
> 
> Any ideas appreciated. 

I'll leave the above unanswered because I think I'm not the right one for that 
question.

> In general I have a hard time seeing how to cleanly
> create packages on Linux, unless we basically ship an entire distro (similar
> to Chrome and others)... I'd love to learn about good approaches, since
> packaging on something "old enough to run everywhere" and "new enough to
> allow all dependencies to be built" seems hard to achieve.

I guess here that you are talking about "cleanness" with respect to 
dependencies. We distro maintainers normally know that this is not easily 
solvable except bundling half of them, which is in turn ugly.

It basically boils down to "one size does not fits all".

> Sadly we don't have the resources to create native packages for each and
> every distro (we want to allow our users to use Qt on older releases of
> their favorite distro) and I'm not sure if packagers would be willing to
> help us get into a situation where it's easy to create packages for all
> relevant distributions, installing into custom prefixes and having a mix of
> versions.

With my Debian maintainer hat on the most complicated thing would be to avoid 
conflicting with existing distro installations. qtchooser can help here tough.

One thing to have in mind: if a user gets qt by using the online 
installer/whatever method coming from you directly and sets it as default Qt 
installation it will have problems with distro apps that uses Qt's private 
headers.

> So for the time being I have been convinced that creating the installers is
> valuable for many people on Linux, but I wonder if there's a way we can do
> better.

I would really be interested here to have actual numbers. We in Debian can 
provide backports if the situation merits it. So far I only see one or two 
people asking us for Qt backports in a year. But maybe that doesn't reflects 
the real necessity for it.

Yes, I understand that here I'm proposing having distro-provided packages 
instead of getting the installations from you directly, but I think that's our 
job if there is really people interested in them out there.

It might be interesting to say that most of the request of having up-to-date 
Qt in stable (or old stable) Debian releases comes from people working at/for 
companies and not from other developers.

I'm of course possibly biased in my answers so *please* do not hesitate in 
asking/proposing other things, I might be missing the elephant in the room. If 
there is anything we can do to improve the situation for our users in a
win-win way then we need to consider it.

-- 
"So long, and thanks for all the fish!"
  The Hitchhickers guide to the Galaxy

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/releasing/attachments/20160411/79d5f8bf/attachment.sig>


More information about the Releasing mailing list