Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

License file is not being added to deb #847

Closed
2 tasks done
andrewlock opened this issue Aug 14, 2024 · 6 comments · Fixed by #849
Closed
2 tasks done

License file is not being added to deb #847

andrewlock opened this issue Aug 14, 2024 · 6 comments · Fixed by #849
Assignees
Labels
bug Something isn't working

Comments

@andrewlock
Copy link

andrewlock commented Aug 14, 2024

What happened?

I'm trying to migrate from fpm to nfpm, and AFAICT, the license field is being ignored.

How can we reproduce this?

configfile:

name: "my-package"
arch: "amd64"
platform: "linux"
version: "3.1.0"
maintainer: "Me <me@testing.com>"
description: "My testing package"
vendor: "Me <me@testing.com>"
homepage: "https://andrewlock.net"
license: "Apache License 2.0"
priority: extra
section: default
scripts:
    postinstall: /some/path/after-install.sh
    postremove: /some/path/after-remove.sh
contents:
- src: /home/testing/linux-x64/
  dst: /opt/me
  type: tree

Then if I run dpkg-deb --info on the output I get:

new Debian package, version 2.0.
 size 114776044 bytes: control archive=1432 bytes.
       1 bytes,     0 lines      conffiles
     274 bytes,     9 lines      control
    2851 bytes,    34 lines      md5sums
      92 bytes,     3 lines   *  postinst             #!/bin/sh
      32 bytes,     2 lines   *  postrm               #!/bin/sh
 Package: my-package
 Version: 3.1.0
 Section: default
 Priority: extra
 Architecture: amd64
 Maintainer: Me <me@testing.com>
 Installed-Size: 309626
 Homepage: https://andrewlock.net
 Description: My testing package

Note that there is no license field. And running dpkg-deb --field license similarly shows it's not set.

nfpm version

_____ ____  __  __
 _ __ |  ___|  _ \|  \/  |
| '_ \| |_  | |_) | |\/| |
| | | |  _| |  __/| |  | |
|_| |_|_|   |_|   |_|  |_|
nfpm: a simple and 0-dependencies apk, arch linux, deb, ipk, and rpm packager written in Go
https://nfpm.goreleaser.com

GitVersion:    2.38.0
GitCommit:     d33a9233bb7acf04621b78114114476196d79779
GitTreeState:  false
BuildDate:     2024-07-05T18:26:41Z
BuiltBy:       goreleaser
GoVersion:     go1.22.5
Compiler:      gc
ModuleSum:     h1:59iH9IPc6GUUk542YBMWw28R1OUEYp7yfOrBC7H+B2Q=
Platform:      linux/amd64

Search

  • I did search for other open and closed issues before opening this.

Code of Conduct

  • I agree to follow this project's Code of Conduct

Additional context

Thanks for this project, I would love to remove our ruby dependency! 😅 I expect I'm just doing something wrong, but I've looked all through the code and can't figure it out. Thanks for your help!

@andrewlock andrewlock added the bug Something isn't working label Aug 14, 2024
@caarlos0
Copy link
Member

hey!

yeah, I think currently you have to copy the license file into the package, something like:

contents:
  - src: ./LICENSE.md
    dst: /usr/share/doc/my-package/copyright
    file_info:
      mode: 0644

@andrewlock
Copy link
Author

Oh, I see, thanks for the info! With fpm we weren't doing that, just specifying the metadata a!d that was it. Thanks, I'll give it a try!

@andrewlock
Copy link
Author

Hmmm, that still hasn't worked 🤔

If I run dpkg -c I can see the copyright file is there:

-rw-r--r-- root/root     11357 2024-03-07 11:30 ./usr/share/doc/my-package/copyright

but it's still not reported by dpkg --info or by dpkg -f my-package_3.1.0_amd64.deb license 🤔

Any more ideas? 😕 Thanks for the help!

@andrewlock
Copy link
Author

andrewlock commented Aug 15, 2024

I was doing a bit more spelunking, and AFAICT, the

RPMMetaData has a license field in the metadata for example:

nfpm/rpm/rpm.go

Line 252 in 52e0c63

Licence: info.License,

The template for the debian control file has no such field:

nfpm/deb/deb.go

Line 716 in 52e0c63

const controlTemplate = `

Compared to fpm which does include it:

https://github.com/jordansissel/fpm/blob/9d3d96a93d6fd667ac21fecf2f91004bfaa77142/templates/deb.erb#L3

Interestingly though, I don't see a specific mention of the License field in the debian control file spec, so I guess fpm is adding it as a "user-defined field"? 🤔

Based on the documentation about copyright information here, your suggestion of just adding the file seems correct, although it also says:

Packages distributed under the Apache license (version 2.0), the Artistic license, the Creative Commons CC0-1.0 license, the GNU GPL (versions 1, 2, or 3), the GNU LGPL (versions 2, 2.1, or 3), the GNU FDL (versions 1.2 or 1.3), and the Mozilla Public License (version 1.1 or 2.0) should refer to the corresponding files under /usr/share/common-licenses, 9 rather than quoting them in the copyright file.

So I think the license file should look something like this (based on examples I found):

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Source: {{HomePage}}
Upstream-Name: {{PackageName}}

Files:
 *
Copyright: {{Year}} {{CopyrightOwner}}
License: Apache-2.0
 Licensed under the Apache License, Version 2.0 (the "License"); you may not
 use this file except in compliance with the License. You may obtain a copy of
 the License at
 .
    http://www.apache.org/licenses/LICENSE-2.0
 .
 Unless required by applicable law or agreed to in writing, software
 distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
 WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
 License for the specific language governing permissions and limitations under
 the License.
Comment:
 On Debian-based systems the full text of the Apache version 2.0 license can be
 found in `/usr/share/common-licenses/Apache-2.0'.

and there shouldn't be a license control field value?

In which case, I think there's probably nothing to do here, though I guess it would be really nice if nfpm could handle this automatically based on the License configuration field 😄 Might be a bit much to ask though! 😄

caarlos0 added a commit that referenced this issue Aug 18, 2024
closes #847

Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
@caarlos0
Copy link
Member

ah, so, I think at least the License field in the control file we can set -> #849

about formatting a license in the specific format needed, maybe that can be left to whoever is packaging it

@andrewlock
Copy link
Author

Ah cool, thank you! 😊

andrewlock added a commit to DataDog/dd-trace-dotnet that referenced this issue Aug 28, 2024
## Summary of changes

Replaces the ruby tool `fpm` with `nfpm` and `tar`

## Reason for change

`fpm` is a ruby tool, which means we have to install ruby. This has
historically caused a bunch of issues at various points when
dependencies change (e.g. we add/update anything or change dockerfiles).

[`nfpm` is a go tool](https://github.com/goreleaser/nfpm) created
specifically to do pretty much the same thing as `fpm`, but without
requiring ruby. The only slightly annoying thing is that it doesn't
support raw "tar" so we have to use the built-in `tar` for that
(although that's not a big hardship).

## Implementation details

- Install `nfpm` in the docker images and remove the `fpm` install (and
removing all the other ruby-related code)
- Call `tar` to pack the `tar` images, and `nfpm` to pack the `deb/rpm`
packages
- `nfpm` is a "config" based tool, so we dump the yaml config to a file,
and pass that to the execution
- I have validated the nfpm and fpm deb output are essentially
identical, there are just a few nuances
- `fpm` adds a `License` field to the `.deb` header, but that's non
standard. [The correct
approach](https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information)
is to include a specific license file. See [this
issue](goreleaser/nfpm#847) for more details.
- Similarly, `fpm` adds a `Vendor` field that is non standard (but
`Maintainer` is standard and is added).
- `fpm` adds `Relocations: /var/datadog` to the `.rpm` header, so I have
replicated that for nfpm, but I don't know that we actually _want_
that... If we let people relocate the headers, then the documentation is
wrong for the profiler env vars etc. Left it as-is anyway, to reduce
chance of breaking people, just something I spotted.
- The `"Apache License 2.0"` license string used for `.rpm` previously
is not a valid value, as defined by fedora, so switched it to the
supported moniker
[here](https://docs.fedoraproject.org/en-US/legal/allowed-licenses/).
- The `tar` files were "accidentally" including the before/after
scripts, so I've made sure to still include them, incase anyone was
relying on those (they run the `createLogPath.sh` file, and create a
symlink to dd-dotnet in `/usr/bin`)

## Test coverage

[Ran a full test with all installers
here](https://dev.azure.com/datadoghq/dd-trace-dotnet/_build/results?buildId=162539&view=results)
- ignore the couple of failures in the dotnet tool smoke tests, those
are failures on `master` I need to fix 😅

Will manually compare the output of this run too:
- [x] tar (`tar -tzvf *.tar.gz`)
- The same, except the before/after scripts weren't being made
executable. Fixed
- [x] deb (`dpkg --info *.deb` and `dpkg -c *.deb`)
  - Minor differences: 
    - nfpm adds the directories as entries
    - nfpm doesn't have the non-standard License field (unlike fpm)
    - nfpm adds the license in the required copyright path
    - nfpm doesn't include a dummy changelog.gz file (unlike fpm)
- [x] rpm (`rpm -qipl --scripts *.rpm`)
- Minor differences, nfpm adds the directories as entries, nothing
significant though

## Other details

Stacked on
- #5770

because we need to change the dockerfiles, and we need the Centos7 fixes
in there at the very least. We'll need to update the VMSS images though
after making these changes so I've been delaying until that makes sense
up to this point.
andrewlock added a commit to DataDog/dd-trace-dotnet that referenced this issue Aug 30, 2024
## Summary of changes

Replaces the ruby tool `fpm` with `nfpm` and `tar`

## Reason for change

`fpm` is a ruby tool, which means we have to install ruby. This has
historically caused a bunch of issues at various points when
dependencies change (e.g. we add/update anything or change dockerfiles).

[`nfpm` is a go tool](https://github.com/goreleaser/nfpm) created
specifically to do pretty much the same thing as `fpm`, but without
requiring ruby. The only slightly annoying thing is that it doesn't
support raw "tar" so we have to use the built-in `tar` for that
(although that's not a big hardship).

## Implementation details

- Install `nfpm` in the docker images and remove the `fpm` install (and
removing all the other ruby-related code)
- Call `tar` to pack the `tar` images, and `nfpm` to pack the `deb/rpm`
packages
- `nfpm` is a "config" based tool, so we dump the yaml config to a file,
and pass that to the execution
- I have validated the nfpm and fpm deb output are essentially
identical, there are just a few nuances
- `fpm` adds a `License` field to the `.deb` header, but that's non
standard. [The correct
approach](https://www.debian.org/doc/debian-policy/ch-docs.html#copyright-information)
is to include a specific license file. See [this
issue](goreleaser/nfpm#847) for more details.
- Similarly, `fpm` adds a `Vendor` field that is non standard (but
`Maintainer` is standard and is added).
- `fpm` adds `Relocations: /var/datadog` to the `.rpm` header, so I have
replicated that for nfpm, but I don't know that we actually _want_
that... If we let people relocate the headers, then the documentation is
wrong for the profiler env vars etc. Left it as-is anyway, to reduce
chance of breaking people, just something I spotted.
- The `"Apache License 2.0"` license string used for `.rpm` previously
is not a valid value, as defined by fedora, so switched it to the
supported moniker
[here](https://docs.fedoraproject.org/en-US/legal/allowed-licenses/).
- The `tar` files were "accidentally" including the before/after
scripts, so I've made sure to still include them, incase anyone was
relying on those (they run the `createLogPath.sh` file, and create a
symlink to dd-dotnet in `/usr/bin`)

## Test coverage

[Ran a full test with all installers
here](https://dev.azure.com/datadoghq/dd-trace-dotnet/_build/results?buildId=162539&view=results)
- ignore the couple of failures in the dotnet tool smoke tests, those
are failures on `master` I need to fix 😅

Will manually compare the output of this run too:
- [x] tar (`tar -tzvf *.tar.gz`)
- The same, except the before/after scripts weren't being made
executable. Fixed
- [x] deb (`dpkg --info *.deb` and `dpkg -c *.deb`)
  - Minor differences: 
    - nfpm adds the directories as entries
    - nfpm doesn't have the non-standard License field (unlike fpm)
    - nfpm adds the license in the required copyright path
    - nfpm doesn't include a dummy changelog.gz file (unlike fpm)
- [x] rpm (`rpm -qipl --scripts *.rpm`)
- Minor differences, nfpm adds the directories as entries, nothing
significant though

## Other details

Stacked on
- #5770

because we need to change the dockerfiles, and we need the Centos7 fixes
in there at the very least. We'll need to update the VMSS images though
after making these changes so I've been delaying until that makes sense
up to this point.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants