[Pkg-osg-devel] Bug: #690878 "pkg-config reports wrong path"

[Manuel A. Fernandez Montecelo]

2012/11/15 Alberto Luaces <aluaces at udc.es>:
>> if I remember correctly, there were some problems if one just do as
>> suggested in the bug report.  Let me check this; I will have an answer
>> before the weekend.
>
> Indeed, there was more than setting the prefix.  Doing so places all the
> installation products under debian/tmp/usr instead of debian/tmp.  I
> have crafted a hacky patch for taking this into account, but I don't
> know if it is worth to have a better solution.  I have written it at the
> end of the post.

Haven't smoke-tested it (try to compile), but I think that your
solution will work.  But upon inspection of "debian/rules", it seems
to me that we are doing two wrongs to get things right, I'll try to
explain.

I think that as alternative to install/move things to (note the double "/usr"):
  $(CURDIR)/debian/tmp/usr/usr/...

one can get the same effect setting:
  make [...] DESTDIR=$(CURDIR)/debian/tmp

instead of:
  make [...] DESTDIR=$(CURDIR)/debian/tmp/usr

That is, the "root" of the target system is set to "debian/tmp", the
application is then installed in prefix "/usr" in the target system,
thus "debian/tmp/usr", and the *.install files will get things right
by using "debian/install" as root of the target system, instead of
having to override it with "dh_install -a --sourcedir=debian/tmp/usr".

Does this sound right?  Did I explain myself?

The changes needed would be then:
-        $(MAKE) -C build/osgstatic DESTDIR=$(CURDIR)/debian/tmp/usr install
+        $(MAKE) -C build/osgstatic DESTDIR=$(CURDIR)/debian/tmp/usr install
 -       $(MAKE) -C build/osg DESTDIR=$(CURDIR)/debian/tmp install
 +      $(MAKE) -C build/osg DESTDIR=$(CURDIR)/debian/tmp install

And setting "CMAKE_INSTALL_PREFIX=/usr", or even removing the line
completely ("/usr" is the default prefix, I think):
                -D CMAKE_INSTALL_PREFIX:PATH=/ \


> On the other hand, lintian throws a lot of
>
> W: openscenegraph: hardening-no-fortify-functions
>
> Since I am not fresh in this one, I can't remember if I set correctly
> the hardening flags or if this is allowable.  Any ideas?

For extensive information, you can read:
http://wiki.debian.org/ReleaseGoals/SecurityHardeningBuildFlags
http://wiki.debian.org/Hardening
http://wiki.debian.org/HardeningWalkthrough

Basically, it's a goal for this upcoming stable release to use extra
flags for the compiler, and thus try to protect from some kind of bugs
that can be exploitable (typically related with C/C++).

Since it's a release goal, I think that modifications of the packages
during freeze is allowed also for this case (but don't take my word
for it).  Since a while ago, with debhelper compat 9, some of these
changes are done automatically with dh commands without need for much
manual intervention [1], but I think that changing to debhelper now
would be too intrusive and not accepted for the stable release.

[1] http://web.dodds.net/~vorlon/wiki/blog/Debian:_not_stale_just_hardened/

All the debhelper compat 9 stuff is quite nice and we should convert
the package to do that, but we will have to wait until after the
release.  See a couple of my packages to see the full niceness of
this, and the super-simple debian/rules possible now (while taking
care of "noopt", "parallel" and so on automagically):

http://anonscm.debian.org/gitweb/?p=pkg-sdl/packages/sdl-image1.2.git;a=blob;f=debian/rules
http://anonscm.debian.org/gitweb/?p=collab-maint/aqsis.git;a=blob;f=debian/rules

tl;dr version: we have to follow the rules from before this was
automatic, as explained in [2], and work around a problem with CMake
which ignores CPPFLAGS by doing what I do in debian/rules from aqsis
(link above).

[2] http://wiki.debian.org/HardeningWalkthrough#Enabling_dpkg-buildflags_in_your_debian.2BAC8-rules_files

Do you want to try to accomodate these changes (Alberto, or Loic)?  I
can do it, although a bit short on time now and in the foreseeable
future, but I think that it's a nice learning experience, if you have
the time and inclination for it :-)


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>