[Development] Co-installation & library naming rules

[Thiago Macieira]

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.

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

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

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.

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.

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

Qt 3 did not have pkgconfig files and our library had a different name then. The 
one program that clashed (qmake) is still a constant source of problems for 
us.

Do we really want to repeat the issue, multiplying it over some more files?

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

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

> Currently, it's not distros proposing this. 

Yes it is. Did you think I came up with this on my own?

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

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