[Development] Co-installation & library naming rules

[Stephen Kelly]

On Friday, September 21, 2012 18:16:48 Thiago Macieira wrote:
> >  find_package(QtCore VERSION 5)
> > 
> > or
> > 
> >  find_package(QtCore VERSION 6)
> 
> This is the right way of doing it,

I agree up to here.

> provided that the VERSION is mandatory.

But I don't agree with this. 

Anyway, I think the names of the cmake files are mostly orthogonal. You're 
talking about distros packages, but cmake find_package isn't what they use 
anyway, so we can drop this part.

> > > Buildsystems based on pkgconfig will often have a requirement of the 
form:
> > > 	QtCore >= 4.6 QtGui >= 4.6
> > > 
> > > or even simply:
> > > 	QtCore QtGui
> > 
> > It is also possible to specify QtGui < 5.0. Any distro where that is
> > needed, but not present is a bug in the distro.
> 
> This is not a permanent solution nor does it work now. There are three
> problems it doesn't solve:
> 
> *Currently*, the packages and dependencies are listed like I listed. We
> cannot require that everyone replace everything now. Won't work.

In transition times, distros either have to be more exact (add < 5.0) or 
change the name entirely (Qt5Core -> Qt6Core). 

Saying it 'won't work' is wrong. They have to do one or the other or their 
packages will be completely broken.

> 
> Further, it won't work for "QtGui < 6.0" since that would select either 4 or
> 5. People would have to write "QtGui >= 4.6 QtGui < 6.0", but as I said,
> reality is different.

"QtGui >= 5.0 QtGui < 6.0", you mean.

In reality, they have to do it, and they will.

> 
> And it doesn't solve the co-installation problem. We need both 4 and 5 to
> install at the same time.

Why? 

If distros decide they want that, then they can put each in a different 
prefix. Why is that for us to do?

> 
> > > Those requirements do match the Qt 5 libraries:
> > > $ pkg-config --libs QtCore \>= 4.6 QtGui \>= 4.6
> > > -L/home/thiago/obj/qt/qt5/qtbase/lib -lQtCore -lQtGui
> > 
> > $ pkg-config --libs QtCore \>= 4.6 QtCore \< 5.0
> > Requested 'QtCore < 5.0' but version of Qtcore is 5.0.0
> > 
> > > Whether that is correct or not is unknown to pkg-config.
> > 
> > But it is known to the user of pkg-config.
> 
> Who didn't think this far ahead. 

If they didn't have enough foresight this time, then they will next time.

now: 

-QtCore >= 4.6
+QtCore >= 4.6 QtCore < 5.0

Later:

-QtCore >= 4.6 QtCore < 5.0
+QtCore >= 5.0 QtCore < 6.0

Even later:

-QtCore >= 5.6 QtCore < 6.0
+QtCore >= 6.0 QtCore < 7.0


> > It seems like it would be nice for pkg-config files to be able to contain
> > a
> > maximum version number for some start-number. Is that possible?
> 
> Sorry, what? I didn't understand.

I was thinking that the pkg-config file itself could know the maximum version 
it can provide, given some starting point. Ie, a pkg-config file for Qt 5 
would throw an error or not consider the package 'found' if it found Qt 6.

I don't know enough about pkg-config to know if that's possible.

Even if it is, it would just be 'nice' anyway, not 'needed'.

> > > The fact that our pkg-config files have the same name also impacts the
> > > co-
> > > installability of Qt 4 and Qt 5, and a little more: Linux distributions
> > > *will* carry Qt 4 for a number of years to come (they still have Qt 3).

Evidence that they can manage this stuff on their own.

> > > Therefore, they must be able to at least have both sets of packages in
> > > their
> > > repositories. The problem comes when their buildsystems make reference
> > > to
> > > pkg- config files, such as in RPM-based distros:
> > > 
> > > BuildRequires: pkgconfig(QtCore)
> > 
> > I don't know anything about RPM, but I would be surprised if they can't
> > specify versions there. If they can't, then that's a global bug for them,
> > not a local one for us.
> 
> They can. But we can't require all distros to patch all their .spec files to
> say < 5.0 and >= 5.0 in other places.

Sure we can. It's completely reasonable.

> We could try and this could be done
> for most distros, but it wouldn't solve the problem of source packages by
> third parties.

What third parties?

> > Why do you think it's our problem to solve and not theirs?
> 
> I don't think it's their problem to solve. I think that this is a correct
> change to do.
> 
> They won't see it as their problem because the GTK camp has already solved
> this problem for years. From their point of view, they'll see us as the ones
> breaking the rules they already have in place.
> 
> And if we refuse to act, they might opt for a path of least resistance and
> rename our files, which in the end hurts us more than it hurts them.

We only 'refuse to act' if distros are already asking us to implement your 
proposal and we say no for the sake of laziness. That's not what's happening 
here though.

Currently, it's not distros proposing this. A credible proposal would have to 
have input and buy-in from debian/suse/redhat/ubuntu packagers. Otherwise we'd 
just be changing things for the sake of it and claiming it's for their 
benefit.

Have you reached out to them already?

Thanks,

-- 
Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-Independent Software Solutions
** Qt Developer Conference: http://qtconference.kdab.com/ **
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120923/aee6d843/attachment.sig>