Notice that the `get_package_data` method will return a list.
so it's clear that the logic `detect_branches` method in ReleaseGenerator and RosReleaseGenerator is same.
In this commit, I reuse this function and put it into ReleaseGenerator's `handle_arguments`
method so that we can safely delete the duplicate part in RosReleaseGenerator.

We need to put the `missing_dep_resolver` in class as staticmethod
in case successor of Generator want to reuse this function.
And I also add os_name, os_versino, ros_distro if oneday the resolver
need more dependency information.

Firstly put the common place/process template files to common.py.
Then, since every pacakge_system has its prefer way of formatting
description and depends, so pass them as function.
Next, rewrite get_sub_hook in DebianGenerator for debian specific
substitutions attribute, and consider generate_cmd will use the hook,
I make the hook as staticmethod method.
At last, fix up the api change influence.

The major different part of RPM and Debian's generator as follow:
1. rpm don't have native option in local generate_cmd related command
2. rpm and debian's Date, changelogs, and License format are different
3. rpm need NoArch substitution
4. rpm has its description and depends specification
And I also update the utils function like __process_template_folder,
__place_template_folder, and place_tempalte_folder, the newest code in
debian should also fit rpm generator's logic

Also fix typo here(unvalid => invalid)

This commit add the missed rosdistro when call super's get_subs_hook
in rosdebian or rosrpm. The release_history should be passed as **kwargs
format since it have default value already.
And I also combine two line in get_release_tag method since it's not
exceed 120 lines.

Neither Fedora or RHEL 7+ use this value. If another distribution were
to be supported for RPM generation in Bloom that can take advantage of
this value, we should find a better way to add it instead of hard-
coding it into the template.

Signed-off-by: Scott K Logan <[email protected]>

Supported in RPM 4.11 and newer:
https://rpm.org/user_doc/autosetup.html

Signed-off-by: Scott K Logan <[email protected]>

...rather than assuming that the make executable is 'make'.

Signed-off-by: Scott K Logan <[email protected]>

Also move terminating '..' to the end to make it easier to patch cmake
arguments and less likely that the make arguments accidentally get
added to the end of the cmake arguments.

Signed-off-by: Scott K Logan <[email protected]>

There are two classes of issues here:
1. ROS packages often provide libraries which are also provided by the
   operating system. If an operating system declares a dependency on
   that library, we don't want the package manager to install the ROS
   package instead of the system package.
2. Many ROS packages don't install libraries in a way that the
   'provides' portion of dependency generation can detect, so when
   another ROS package takes a dependency on that library, the
   automatic dependency can't be met and the downstream package
   cannot be installed.

More info on RPM dependency generation:
https://rpm.org/user_doc/dependency_generators.html

Signed-off-by: Scott K Logan <[email protected]>

The BRP Python bytecompiler will always use the sytem's default Python
interpreter, which may not be the interpreter we're targeting. Safest
option is to disable the automagic byte compilation altogether.

Note that this doesn't mean that python files won't ever be compiled,
it just means that the catch-all policy at the end of the process won't
attempt to compile anything which hasn't already been compiled.

Signed-off-by: Scott K Logan <[email protected]>

This change shouldn't modify the behavior in Fedora, where all current
releases define 'cmake3' to be the same as 'cmake'. In RHEL 7, where
cmake 2 is the default, we need to use the 'cmake3' macro to use the
supplamental 'cmake3' executable instead of the system default.

All current ROS releases except Indigo have a *minimum* cmake
requirement of 3.

Signed-off-by: Scott K Logan <[email protected]>

…e#540)

The SCM plugin for mock will create an archive of the sources if either
this marker file is present in the root of the project or the
`write_tar` option is specified in mock's configuration.

The way bloom works, we always want to archive the sources, but this
isn't the default configuration of the SCM plugin. Writing this marker
file means one less configuration is necessary when consuming the
release repo to build the RPMs with mock.

Signed-off-by: Scott K Logan <[email protected]>