Closed shirishag75 closed 7 years ago
Thanks for reporting
could you reopen it, have more details , dunno if you want to some more stuff, from debhelper documentation - man debhelper -
v8 Changes from v7 are:
- Commands will fail rather than warning when they are passed unknown options.
- dh_makeshlibs will run dpkg-gensymbols on all shared libraries that it generates shlibs files for. So -X can be used to
exclude libraries. Also, libraries in unusual locations that dpkg-gensymbols would not have processed before will be
passed to it, a behavior change that can cause some packages to fail to build.
- dh requires the sequence to run be specified as the first parameter, and any switches come after it. Ie, use "dh $@
--foo", not "dh --foo $@".
- dh_auto_* prefer to use Perl's Module::Build in preference to Makefile.PL.
This mode is deprecated.
v9 Changes from v8 are:
- Multiarch support. In particular, dh_auto_configure passes multiarch directories to autoconf in --libdir and
--libexecdir.
- dh is aware of the usual dependencies between targets in debian/rules. So, "dh binary" will run any build, build-arch,
build-indep, install, etc targets that exist in the rules file. There's no need to define an explicit binary target with
explicit dependencies on the other targets.
- dh_strip compresses debugging symbol files to reduce the installed size of -dbg packages.
- dh_auto_configure does not include the source package name in --libexecdir when using autoconf.
- dh does not default to enabling --with=python-support
- All of the dh_auto_* debhelper programs and dh set environment variables listed by dpkg-buildflags, unless they are
already set.
- dh_auto_configure passes dpkg-buildflags CFLAGS, CPPFLAGS, and LDFLAGS to perl Makefile.PL and Build.PL
- dh_strip puts separated debug symbols in a location based on their build-id.
- Executable debhelper config files are run and their output used as the configuration.
v10 This is the recommended mode of operation.
Changes from v9 are:
- dh_installinit will no longer install a file named debian/package as an init script.
- dh_installdocs will error out if it detects links created with --link-doc between packages of architecture "all" and
non-"all" as it breaks binNMUs.
- dh no longer creates the package build directory when skipping running debhelper commands. This will not affect packages
that only build with debhelper commands, but it may expose bugs in commands not included in debhelper.
- dh_installdeb no longer installs a maintainer-provided debian/package.shlibs file. This is now done by dh_makeshlibs instead.
- dh_installwm refuses to create a broken package if no man page can be found (required to register for the x-window-
manager alternative).
- Debhelper will default to --parallel for all buildsystems that support parallel building. This can be disabled by using
either --no-parallel or passing --max-parallel with a value of 1.
- The dh command will not accept any of the deprecated "manual sequence control" parameters (--before, --after, etc.).
Please use override targets instead.
- The dh command will no longer use log files to track which commands have been run. The dh command still keeps track of
whether it already ran the "build" sequence and skip it if it did.
The main effects of this are:
- With this, it is now easier to debug the install or/and binary sequences because they can now trivially be re-run (without having to do a full "clean and rebuild" cycle)
- The main caveat is that dh_* now only keeps track of what happened in a single override target. When all the calls
to a given dh_cmd command happens in the same override target everything will work as before.
Example of where it can go wrong:
override_dh_foo:
dh_foo -pmy-pkg
override_dh_bar:
dh_bar
dh_foo --remaining
In this case, the call to dh_foo --remaining will also include my-pkg, since dh_foo -pmy-pkg was run in a separate
override target. This issue is not limited to --remaining, but also includes -a, -i, etc.
- The dh_installdeb command now shell-escapes the lines in the maintscript config file. This was the original intent but
it did not work properly and packages have begun to rely on the incomplete shell escaping (e.g. quoting file names).
- The dh_installinit command now defaults to --restart-after-upgrade. For packages needing the previous behaviour, please
use --no-restart-after-upgrade.
- The autoreconf sequence is now enabled by default. Please pass --without autoreconf to dh if this is not desirable for a
given package
- The systemd sequence is now enabled by default. Please pass --without systemd to dh if this is not desirable for a given package.
I will fix the formatting issues once I see how it looks, github doesn't provide a preview button unfortunately.
See http://unix.stackexchange.com/a/322874/50490 . Basically 9 gives multiarch support while 10 gives parallel builds, specifically for parallel builds -
http://askubuntu.com/questions/337093/how-to-run-parallel-make-with-debuild
in essence just changing from dh $@ --with autoreconf
to dh $@ --parallel --with autoreconf
should make compilation easier for those who have multiple cores and want to use them while compiling for a shorter time.
I do not understand what exactly should I do?
last line in debian/rules, I think you can change it from dh $@ --with autoreconf
todh $@ --parallel --with autoreconf
But why, all of the packages in Debian can have this?
It will... in due course of time. The whole idea of Debian Policy is that Debian Packagers and Managers implement it as and when. There are still packages which just updated to dh 9 (i.e. Debian Policy 9) and others which have updated to dh 10 (Debian Policy 10) . Sooner or later all will have this feature so that autobuilders take less time to build the archive . See https://www.debian.org/devel/buildd/ as well as https://buildd.debian.org/stats/ but is not necessary. This is more of a wishlist thing atm.
I-Nex and its makefile does not support at this moment functions --parallel .
While there may be other changes that need to be done, can you for now at least just bump compat file from 7 to 9
I ask otherwise I get a warning while trying to compile or cleaning for that matter -
If any issues do come up lintian will come with it and we will together try to figure it out.