[Interest] -headerdir causing headerfile version confusion building qtwebengine (was Qt5 cannot be build on Debian Wheezy? GLIBCXX_3.4.20' not found)

[Thiago Macieira]

On Tuesday 20 January 2015 00:08:10 René J.V. Bertin wrote:
> On Monday January 19 2015 14:30:28 Thiago Macieira wrote:
> > to -headerdir. (yes, it is in the qtwebengine case, but I'm talking in
> > generic)
> 
> So, is the qtwebengine case a bug or something that would be fixed when I
> submit a patch?

It's a bug caused by a workaround to another bug. The ideal solution is to fix 
the original bug in the first place. If you can't do that, you may reintroduce 
the issue by removing the workaround.

So lose-lose situation.

> > I don't have to. This is standard practice already. All the major Linux
> > distros build their packages like I described. Look at Fedora's Koji or
> > the
> > Open Build System or what Debian uses. Take a look at Scratchbox too.
> 
> I can only speak for Debian and Ubuntu and for those that is true for the
> packages that they ship, and for PPAs people can create. But do you really
> think that Debian or Ubuntu maintainers develop their packages starting
> with a clean install every time (creating a new VM each time as launchpad
> does)? Every Ubuntu package that I've tried to build locally builds just
> fine. And I don't have the impression that dpkg-build sets up some sort of
> chroot.

I don't know how the developers develop their packages. They probably use 
their local systems, indeed. They don't need a full on VM, though: a simple 
chroot environment is enough and that's exactly what the OBS local client 
does. In any case, all of those have the devel/non-devel separation, so it's 
very easy for the developers to remove the development packages before trying 
the new build.

But I can tell you that the distros' official build does use isolated 
environments. This is what counts since it's what builds the packages that 
people actually use.

> > weird errors, elsewhere. A bad config.h might result in disabled features
> > on an otherwise fully-working application, so you'd spend a lot of time
> > debugging to find out that it was caused by a left-over build of an
> > unrelated package that the user built herself...
> 
> Common MacPorts debugging (or debunking :)) practice is to ask the user for
> the build log first. Then again chances that a lambda MacPorts user runs
> into this kind of problem are small, for various reasons among which the
> fact that the port build system sets up a kind of sandboxed environment.

The log wouldn't include the fact that there's a file that wasn't installed by 
MacPorts in the first place (unless it sends a file listing of the entire 
system, which is a huge privacy and security nightmare).

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center