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 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 , but I think that changing to debhelper now would be too intrusive and not accepted for the stable release.  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 , and work around a problem with CMake which ignores CPPFLAGS by doing what I do in debian/rules from aqsis (link above).  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.montez...@gmail.com> _______________________________________________ Pkg-osg-devel mailing list Pkgfirstname.lastname@example.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-osg-devel