Add a base_name option to Debian packager

[jefmathiot]

The name of the output file is currently inherited from the project. One could want to change the file name (say to my-project-ubuntu_1.2.3-1.amd64.deb) but keep the name of the package identical (my-project). For example, I needed to build two different packages using the same packager (Debian) but apply two different provisioning recipes depending on the build platform. This modification would avoid a name clash on the resulting artefacts:

build_platform = ohai['platform']

package :deb do
  ...
  base_name "my-software-#{build_platform}"
end

[jefmathiot]

I'm not sure if other packagers could benefit of this modification (RPM, I guess). I'd be glad to push additional commits to the PR if appropriate.

[schisamo]

@jefmathiot Just so I understand your use case better...this clashing is happening on the same build machine?

[jefmathiot]

@schisamo we have a Vagrantfile spawning 4 boxes (Debian & Ubuntu each on i386 and amd64 architectures). The provisioning is the same on both the platforms but the resulting packages are not identical : we're actually building both platforms separately because of issues with libc. My comment in the PR was not clear (sorry), there is no clash at all if we provision the VMs one at a time. The name clash appears as we provision all the boxes in sequence with the same packager in the same synced folder (the Ubuntu32 box will create an xxx-i386.deb package soon replaced by the build on the Debian32 box).

[jefmathiot]

Another use case could be to add a build number - say, the abbreviated SHA-1 of a git revision to the filename.

[schisamo]

@jefmathiot That's how the Omnibus::BuildVersion#semver works currently:
https://github.com/opscode/omnibus/blob/master/lib/omnibus/build_version.rb#L61-L121

We use this build version format in most all of our projects.

[chef-supermarket]

Hi. I am an automated pull request bot named Curry. There are commits in this pull request whose authors are not yet authorized to contribute to Chef Software, Inc. projects or are using a non-GitHub verified email address. To become authorized to contribute, you will need to sign the Contributor License Agreement (CLA) as an individual or on behalf of your company. You can read more on Chef's blog.

GitHub Users Who Are Not Authorized To Contribute

The following GitHub users do not appear to have signed a CLA:

• @jefmathiot

Please sign the CLA here.

[chef-supermarket]

Hi. Your friendly Curry bot here. Just letting you know that all commit authors have become authorized to contribute. I have added the "Signed CLA" label to this issue so it can easily be found in the future.

[chef-supermarket]

Hi. I am an automated pull request bot named Curry. There are commits in this pull request whose authors are not yet authorized to contribute to Chef Software, Inc. projects or are using a non-GitHub verified email address. To become authorized to contribute, you will need to sign the Contributor License Agreement (CLA) as an individual or on behalf of your company. You can read more on Chef's blog.

GitHub Users Who Are Not Authorized To Contribute

The following GitHub users do not appear to have signed a CLA:

• @ehartmann

Please sign the CLA here.

[chef-supermarket]

Hi. Your friendly Curry bot here. Just letting you know that all commit authors have become authorized to contribute. I have added the "Signed CLA" label to this issue so it can easily be found in the future.

[scotthain]

Just as an fyi - this will totally break things that aren't x86 based. We should probably stick with Ohai['kernel']['machine']

[ehartmann]

@scotthain understood, the issue that leads us to use to change the detection is that using a 32bits Docker container (on a 64bits kernel) is detected as a 64bits OS.