[Development] Not stripping our binaries by default

Thiago Macieira thiago.macieira at intel.com
Sat Sep 15 08:52:58 CEST 2012


On sábado, 15 de setembro de 2012 01.54.29, Laszlo Papp wrote:
> > I disagree and I think we ought to think more about them. Especially
> > since,
> > without my fix, they had to patch Qt.
> 
> This is not what you tried to achieve with the tarball distribution even
> when packager(s) asked explicitely so. The packagers were not considered as
> said they should all solve on their own when needed.

There's a huge difference between stripping the binaries and the format of the 
package. In one case, it's a minor nuisance to some that in no way prevents 
work from happening (there's a .gz) and it's quickly going away as technology 
improves.

In the other, it's a major problem that requires a non-trivial process of 
investigating why the build process produced small debuginfo packages (first 
problem: they might not notice the issue), is quite non-standard and, up until 
now, required reading the qmake source code to figure out how to patch a 
solution.

I'm sure you see the huge gap between those two cases. 

If you reply to this email to continue arguing your case, please include the 
words, "Yes, I understand they are totally different" before adding your new 
arguments.

> Moreover, why would they have to do that if there is an option as planned
> previously?

There was no option previously planned. I'm adding one now. So read what I 
said: "without my fix, they had to patch Qt".
-- 
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/20120915/d0d7b099/attachment.sig>


More information about the Development mailing list