2012/11/15 Alberto Luaces <alua...@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
I think that as alternative to install/move things to (note the double "/usr"):
one can get the same effect setting:
make [...] DESTDIR=$(CURDIR)/debian/tmp
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:
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 , but I think that changing to debhelper now
would be too intrusive and not accepted for the stable release.
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):
tl;dr version: we have to follow the rules from before this was
automatic, as explained in , and work around a problem with CMake
which ignores CPPFLAGS by doing what I do in debian/rules from aqsis
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 :-)
Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
Pkg-osg-devel mailing list