On 17/12/15 10:02, Antonio Trande wrote:

On 12/17/2015 10:17 AM, Piotr Popieluch wrote:

...

Hi,

I've encountered a couple times that an upstream project adds the full license text to the end of a readme file. It is not clear to me how to handle these situations. What to do:

1. add readme file only to %doc 2) add readme file only to

%license 3) add readme to both %doc and %license 4) cut file in two parts

Upstream should provide a complete text file of the license. How is license reported in README file?

Well the review that triggered this related to this README file:

https://github.com/TooTallNate/array-index/blob/master/README.md

Which has the full text of the license at the end of it.

The packager had put the file in both %doc and %license and my comment as reviewer was that %license was only supposed to be for when the license was "in its own file".

The current solution has been for the spec to copy the license out of the README to a separate file and add that to %license.

Tom

On Thu, Dec 17, 2015 at 10:53:09AM +0000, Mat Booth wrote:

...

1. add readme file only to %doc
2. add readme file only to %license
3. add readme to both %doc and %license
4. cut file in two parts

Actually I don't mind options 1, 2 or 3 (all of these options fulfil the legal obligations of the license, right?) -- 4 seems like unnecessary effort for no real gain.

Don't forget the "nodocs" use case, which the separate license tag helps cover. That means 2 or 3 is preferable to 1. My suggestion would be to go with 3 and then to ask upstream to separate it out. Ideally, if they're using a standard license, we can in the future deduplicate identical license files, too, but only if they're just the license alone in a file.

On 12/17/2015 11:04 AM, Stephen Gallagher wrote:

On 12/17/2015 07:30 AM, Matthew Miller wrote:

...

On Thu, Dec 17, 2015 at 10:53:09AM +0000, Mat Booth wrote:

...

...

1. add readme file only to %doc 2) add readme file only to

%license 3) add readme to both %doc and %license 4) cut file in two parts

Actually I don't mind options 1, 2 or 3 (all of these options fulfil the legal obligations of the license, right?) -- 4 seems like unnecessary effort for no real gain.

...

Don't forget the "nodocs" use case, which the separate license tag helps cover. That means 2 or 3 is preferable to 1. My suggestion would be to go with 3 and then to ask upstream to separate it out. Ideally, if they're using a standard license, we can in the future deduplicate identical license files, too, but only if they're just the license alone in a file.

Just to clarify, Option 1 would not in fact be legally acceptable in many cases (because installation with --nodocs could then result in an installation that did not meet license requirements of having the text present on the installed system).

this macro is documented under packaging for epel wiki

%{!?_licensedir:%global license %doc}

...

...

...

...

"SG" == Stephen Gallagher sgallagh@redhat.com writes:

SG> EPEL is a special case, it doesn't have the necessary distinguishing SG> features in RPM to do %license.

Give it a bit; I'm trying to fix that. Actually I already have in EL6; see the epel-rpm-macros package in epel6-testing. It's unfortunately more complicated that it seems, and I'm rebuilding all of EL6 to make sure I'm not breaking anything. EL5 will be next, and hopefully I can get rid of some of the other annoyances as well.

Of course, even after I do this, it will still be an alias to %doc, but at least you won't have to worry about it.

- J<

...

...

...

...

"NG" == Neal Gompa ngompa13@gmail.com writes:

NG> With this macros package, do we get to use nice things like NG> %make_build (rpm 4.12+) and %autosetup/%autopatch (rpm 4.11+) with NG> %EL releases that don't support them?

Uh, well, with the current package, no. Because it just does one thing: enables %license.

I will add your requests to my list (which I will commit to the epel-rpm-macros repository in pkgs real soon now. I think both of those should be possible and even easy if they're just plain macros.

The plan is to add the python macros as well. But for now I need to get the package fully tested and then submit a request to get it into the EL6 buildroot, and then repeat the whole process with EL5. Once all that is done then I can get down to adding macros that people request.

I imagine that most of the discussion about new macros will happen in epel-devel but I follow this list as well.

- J<