[Development] New proposal for the tool naming

[Thiago Macieira]

On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote:
> > We've been over this: because I'd rather do this right and once and for
> > all. Who are the best people to make sure that all tools continue to work
> > under those conditions? Upstream is.
> 
> the thing is that this is a non-change. *nothing* needs to be changed in
> the sources - it's only a question of where the package manager is told
> to put the executable. i don't see why we should introduce any
> complexity upstream for a problem that is cleanly solved by downstream
> for decades.

You do realise that there has been *no* clean solution developed downstream, 
right? Much less for decades.

Renaming qmake to qmake-qt4 is not a clean solution. Our heretofore 
requirement of changing PATH has been largely ignored by everyone on the Linux 
world, and has been applied to the Mac world only recently (up until the SDKs, 
we distributed globally-installed frameworks).

History so far shows that if we don't do it, distributions won't do it cleanly 
either. I have much more confidence in them getting it right if *we* get it 
right for them. I'd much rather make it easier for them by making it so they 
have to do very little or nothing.

I know packagers are intelligent people, but they're also busy people. Qt is 
hardly the only package they take care of. But it's one that takes a 
disproportionate amount of resources to maintain and also to build.

> > > i'm pretty sure that *some* build systems rely on moc being in the path.
> > > one could argue that they are broken - but then, it exactly fits the
> > > /usr/bin philosophy, so it's hard to blame them.
> > 
> > We've been over this, again. If they rely on $PATH without user
> > intervention, they are already broken, as /usr/bin/moc might be Qt 4's.
> 
> they are not broken, because relying on a correctly set up $PATH is an
> entirely reasonable position. 

I beg to differ, again. That's the position we've been taking for the 15 years 
of the existence of moc and the 10 years of qmake, but we've not been listened 
to.

We may think and we definitely have thought it was reasonable to ask. But 
history shows that we haven't been listened to. Therefore, it's not reasonable 
to *keep* asking.

> the problem you are trying to solve is
> limited to co-installation into a single path, which is a policy-imposed
> problem of linux distributions. it is incredibly silly to claim that
> something that does not comply with this policy is broken by definition.

I understand and even agree with your interpretation: the brokenness isn't our 
doing, not alone anyway.

Nevertheless, it is broken. Blame all you want the distributors. They won't 
change their policies for us or for the handful of other packages that aren't 
distro-friendly.

We have a saying in Portuguese, "dar murro em ponta de faca" (roughly 
translates to "punching the pointy edge of a knife"), which applies to when 
one insists in doing something painful and clearly ill-advised. Insisting on 
our Qt 4 advice is that, since there's no indication our advice will be 
listened to any more than in the past.

We tried, we failed. Time to try something different.

> > True, but unlike lupdate, the functionality, purpose and output do not
> > change from version to version. The Qt 5 xmlpatterns cleanly replaces the
> > old Qt 4 one. There's no need to duplicate.
> 
> your idea doesn't work anyway. the distros won't have the users install
> the qt5 libraries just because the user requested an xmlpatterns
> package, when a qt4-based xmlpatterns can be had almost for free for
> those which already have qt4 libs installed. and some distros won't have
> two alternative xmlpatterns packages which provide the same binary -
> because of non-conflict policies. the bottom line is that there will be
> qt version bound sets of all tools and apps, and that they will have to
> meet the co-installability requirements.

The difference is that xmlpatterns, like qdbus and the other applications, can 
be updated by the Debian alternatives mechanism. They're just two different 
implementations of the same functionality.

The solution for that problem already exists.

The solution for the qmake problem does not, at least not a solution that has 
been applied.

Though I want to hear from distros what they think of the fact that Designer 
is being put in the same bucket.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
-------------- 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/20121023/efded5af/attachment.sig>