[Development] Co-installation & library naming rules

[Thiago Macieira]

On domingo, 23 de setembro de 2012 18.00.26, Stephen Kelly wrote:
> > > > > 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'.
> > 
> > It still does not make sense. How would QtCore.pc version 4.8.3 know
> > anything about QtCore.pc 5?
> 
> I'm assuming it doesn't need to. Chalk that up to me making assumptions
> about how pkg-config works.

It reads a .pc file, compares the version numbers, then prints information.

I still don't get how you want pkg-config to guess that the user meant "not Qt 
5" when the user didn't write "< 5.0".

> > But a generic pkgconfig call cannot do that because the user may have
> > meant
> > Qt 5. It can't consider Qt 5 not present, unless we stop installing a
> > QtCore.pc file -- and that's what I'm calling for.
> 
> ... or unless the -devel packages are not coinstallable (as is currently the
> case). So far we have Fedora asking for that. Can we get more input on
> whether they need to be coinstallable?

They need to be. That's the source of the bug report: the two versions have 
the same .pc file names.

> > The ones linking to Qt but not using qmake or cmake.
> 
> Vanishingly irrelevant imo.

Probably. But we've been saying for 7 years that pkg-config is the official way 
of finding Qt. CMake's use of qmake is non-standard.

> You're re-writing the book on how to rename a library, according to your
> initial email. In my mind that's something to do:
> 
> * cautiously
> * with buy-in from stakeholders and those affected and reachable
> * with understanding of the reasons it has to be done this way and not
> another
> 
> So that's why I'm replying here.

They want co-installation of all files. I'm simply making a proposal on how to 
achieve that now and in the future.

But yeah, they need to review the proposal too. I was hoping they'd have 
pitched in by now.

> You wrote that it is the first light for the idea in words like this.

The first time I've seen it phrased like that. Not the first time it's used, 
since I'm following existing practice of the Gtk libs.

> A credible proposal for me would be one which Sune/Modestas Vainus,
> Riddell/Harald Sitter, Will Stephenson, and maybe the unix-but-non-linux
> people like Raphael Kubo da Costa all buy-into. That doesn't appear to be
> what we have.

They haven't replied yet. But this is something they should.

> I'm sure they're all on the kde-packager mailing list though, so you might
> even be able to reach them all in one go. That's a private list, so you'd
> have to ask them to reply/discuss here.

Then that's off. If they want to package Qt, they come to us. I've called for 
packagers to join this list and/or the releasing mailing list more than once. 
I understand everyone is busy and I only posted this on Friday, so let's give 
them time to understand the proposal and support it, or point out the issues.

> In summary:
> 
> I don't think it's a good idea to sprint towards an implementation of your
> proposal until it has credible buy-in from 'outside' of the Qt-Project.

Agreed.

> I'm not really opposed to it and won't stand in the way of a credible
> implementation of it. My mails here are an attempt to understand why your
> proposal is the only/best way.

I think the proposal spoke for itself. Goal: co-installation of all files.

The current Qt Project's position is that we don't support that. We require Qt 
to be installed in different prefixes and we don't like our tools being renamed 
(including qmake). It works and we all know it does -- I have about 10 
different checkouts / builds of Qt on my laptop and they never stand on each 
other's way.

We can continue down that road and packagers will do what they've done to Qt 
4, multiplied by several more files. Or we can be a good citizen and just do 
what everyone else does.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120923/16ab123e/attachment.sig>