From Fedora Project Wiki
(create from template)
 
No edit summary
Line 1: Line 1:
{{admon/important | Comments and Explanations | The page source contains comments providing guidance to fill out each section. They are invisible when viewing this page. To read it, choose the "edit" link.<br/> '''Copy the source to a ''new page'' before making changes!  DO NOT EDIT THIS TEMPLATE FOR YOUR CHANGE PROPOSAL.'''}}
{{admon/important | Comments and Explanations | MOSTLY EMPTY DRAFT }}


<!-- Self Contained or System Wide Change Proposal?
Use this guide to determine to which category your proposed change belongs to.


Self Contained Changes are:
= Use license macro in RPMs for packages in Cloud Image =
* changes to isolated/leaf package without the impact on other packages/rest of the distribution
* limited scope changes without the impact on other packages/rest of the distribution
* coordinated effort within SIG with limited impact outside SIG functional area, accepted by the SIG
 
System Wide Changes are:
* changes that does not fit Self Contained Changes category touching
* changes that require coordination within the distribution (for example mass rebuilds, release engineering or other teams effort etc.)
* changing system defaults
 
For Self Contained Changes, sections marked as "REQUIRED FOR SYSTEM WIDE CHANGES" are OPTIONAL but FESCo/Wrangler can request more details (especially in case the change proposal category is
improper or updated to System Wide category). For System Wide Changes all fields on this form are required for FESCo acceptance (when applies). 
 
We request that you maintain the same order of sections so that all of the change proposal pages are uniform.
-->
 
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
 
= Change Proposal Name <!-- The name of your change proposal --> =


== Summary ==
== Summary ==
<!-- A sentence or two summarizing what this change is and what it will do. This information is used for the overall changeset summary page for each release. -->
Use new %license macro to separate license files from documentation, so the latter can be excluded from container images without stripping license information which must be included.


== Owner ==
== Owner ==
<!--
* Name: [[User:mattdm| Matthew Miller]]
For change proposals to qualify as self-contained, owners of all affected packages need to be included here. Alternatively, a SIG can be listed as an owner if it owns all affected packages.
* Email: mattdm at fedoraproject
This should link to your home wiki page so we know who you are.
-->
* Name: [[User:FASAcountName| Your Name]]
<!-- Include you email address that you can be reached should people want to contact you about helping with your change, status is requested, or technical issues need to be resolved. If the change proposal is owned by a SIG, please also add a primary contact person. -->
* Email: <your email address so we can contact you, invite you to meetings, etc.>
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
* Release notes owner: <!--- To be assigned by docs team [[User:FASAccountName| Release notes owner name]] <email address> -->
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
Line 45: Line 20:


== Current status ==
== Current status ==
* Targeted release: [[Releases/<number> | Fedora <number> ]]  
* Targeted release: [[Releases/21 | Fedora 21]]  
* Last updated: (DATE)
* Last updated: 2014-04-04
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
<!-- After the change proposal is accepted by FESCo, tracking bug is created in Bugzilla and linked to this page  
Bugzilla states meaning as usual:
Bugzilla states meaning as usual:
Line 58: Line 33:


== Detailed Description ==
== Detailed Description ==
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
 
Background:
 
1. Right now, license files are required to be marked as %doc files.
2. There has long been a "nodocs" parameter to RPM which skips all doc files.
3. In addition to the desired space-savings, this installs packages without their possibly-mandatory license files
 
This interaction hasn't been problematic before, because generally using nodocs is an endpoint choice with no distribution after that. But now, we are looking at building some official cloud and container images with nodocs, so it suddenly becomes important.
 
As a bonus, in the future, %license may handle automatic hardlinking of identical license files.
 
Specifically, I propose:
 
1. We change the guidelines
2. We start doing it for new packages
3. We file a F21 system-wide change (that is, ''this'' change) for a proven packager to change all the packages that land in the cloud image for F21 (roughly, @core + dependencies plus a few extras)
4. For next release, we file a system-wide change for F22 to update all other packages which are part of the base design
5. Other packages updated on a as-time-permits/best-effort basis


== Benefit to Fedora ==
== Benefit to Fedora ==

Revision as of 18:21, 4 April 2014

Important.png
Comments and Explanations
MOSTLY EMPTY DRAFT


Use license macro in RPMs for packages in Cloud Image

Summary

Use new %license macro to separate license files from documentation, so the latter can be excluded from container images without stripping license information which must be included.

Owner

Current status

  • Targeted release: Fedora 21
  • Last updated: 2014-04-04
  • Tracker bug: <will be assigned by the Wrangler>

Detailed Description

Background:

1. Right now, license files are required to be marked as %doc files. 2. There has long been a "nodocs" parameter to RPM which skips all doc files. 3. In addition to the desired space-savings, this installs packages without their possibly-mandatory license files

This interaction hasn't been problematic before, because generally using nodocs is an endpoint choice with no distribution after that. But now, we are looking at building some official cloud and container images with nodocs, so it suddenly becomes important.

As a bonus, in the future, %license may handle automatic hardlinking of identical license files.

Specifically, I propose:

1. We change the guidelines 2. We start doing it for new packages 3. We file a F21 system-wide change (that is, this change) for a proven packager to change all the packages that land in the cloud image for F21 (roughly, @core + dependencies plus a few extras) 4. For next release, we file a system-wide change for F22 to update all other packages which are part of the base design 5. Other packages updated on a as-time-permits/best-effort basis

Benefit to Fedora

Scope

  • Proposal owners:
  • Other developers: N/A (not a System Wide Change)
  • Release engineering: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes