[Development] Co-installation & library naming rules

[Stephen Kelly]

On Sunday, September 23, 2012 16:06:46 Thiago Macieira wrote:
> On domingo, 23 de setembro de 2012 13.10.32, Stephen Kelly wrote:
> > In transition times, distros either have to be more exact (add < 5.0) or
> > change the name entirely (Qt5Core -> Qt6Core).
> 
> We do not want them to rename. That would be bad for everyone involved. So
> they need to replace the requirement in all of their control files.
> 
> And all the third parties need to do it in their non-qmake and non-cmake
> requirement files too. Granted, there aren't many.
> 
> > Saying it 'won't work' is wrong. They have to do one or the other or their
> > packages will be completely broken.
> 
> That's what I'm trying to do: avoid breaking them.

There seems to be misunderstanding somewhere. Let's ignore that for now 
though.

> 
> > > 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?
> 
> Because there is only one prefix for distributions: /usr. They do not like
> installing elsewhere. We're not going to change 20 years of practice with
> our 5.0 release.
> 
> So each one will do different hacks to support their systems and policies.
> And LSB 5 will also have an "optional module" that is separate, opt-in,
> instead of the default.
> 
> How about instead we just align with everyone else's practices?

We'd need to be really sure what everyone elses practices are. So far we've 
heard from Fedora about what they do with Qt 4 and we've heard from them that 
GTK+ puts version numbers in .pc file names.

I think a more complete picture is needed to call it 'everyone else'.

> 
> > > > 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.

> 
> You must be thinking of a "FindQt4" tool like cmake's, which uses pkg-config
> to find Qt 4. In that case, yeah, it can consider that Qt 5 is not Qt 4,
> and it isn't.

I'm not thinking of any combination of pkg-config and cmake.

> 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?

> > > 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?
> 
> The ones linking to Qt but not using qmake or cmake.

Vanishingly irrelevant imo.

> 
> > > > 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.
> 
> That's exactly what's happening. I'm bringing the proposal to the table and
> you're starting to resist it.

I'm not really resisting it. 

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.

> 
> > Currently, it's not distros proposing this.
> 
> Yes it is. Did you think I came up with this on my own?

In its current form and the current concrete proposal, yes. 

You wrote that it is the first light for the idea in words like 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?
> 
> The proposals come from the distros. Starting from Fedora, in the bug
> report. Did you read it?

Yes. It doesn't just start with Fedora. It ends with them too. And the dialog 
in the bug report predates this proposal on the mailing list.

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.

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.

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.

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.

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/59b65ad5/attachment.sig>