[Development] Pending decisions on co-installation

[Thiago Macieira]

On terça-feira, 30 de outubro de 2012 23.52.08, André Pönitz wrote:
> On Tue, Oct 30, 2012 at 01:47:03PM -0700, Thiago Macieira wrote:
> > 5) executable split between end-user applications and indirect tooling
> > The most controversial proposal so far is to split the binaries into two
> > groups: one that gets installed to PREFIX/bin, containing the executables
> > for applications run directly by the user and which retain backwards
> > compatibility of purpose, and one that gets installed to ARCHDATADIR/bin
> > that contains the tools that users generally do not run directly and
> > which are specific to a particular build of Qt. Please note that, in the
> > current implementation, like in #4 above, most people on this list will
> > not see a change, as it applies to Unix builds that require make install
> > *only*.
> > 
> > This proposal has met with vehement opposition and I'd like to hear why.
> 
> "There is no clear cut between applications directly run by the users and
> those that are generally not run directly. In some cases it is clear, in
> some others it depends on the actual user's habits, and no matter where
> a cut is made for someone it will be wrong."

And if we define the cut as the ones that have compatibility of purpose and 
output, versus the ones that don't?

Assistant is meant to visualise documentation and its input files remain 
compatible. Designer edits .ui files and its output is compatible, even 
backwards compatible, or could be made so in the Save dialog (like Word or 
LibreOffice).

However, moc doesn't retain compatibility and its output is not backwards 
compatible.


In any case, what's the problem with making a subjective decision? Clearly the 
applications need to be split in two groups, so why shouldn't the Qt Project 
make its recommendation to the downstreams?
-- 
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/20121030/4ffd2792/attachment.sig>