< Features
m (Add testing stuff.) |
(Move out of beta) |
||
| Line 1: | Line 1: | ||
<!-- Self Contained or System Wide Change Proposal? | <!-- Self Contained or System Wide Change Proposal? | ||
Use this guide to determine to which category your proposed change belongs to. | Use this guide to determine to which category your proposed change belongs to. | ||
| Line 59: | Line 57: | ||
== Detailed Description == | == Detailed Description == | ||
Currently we know how to make an installable OS with packages that doesn't require the use of scriptlets, indeed rpm-ostree and others have already done this on a significantly bigger scale. So we plan to remove direct scriptlets from most (if not all) of the packages in the main fedora container image for Fedora 31. This means all four of: %pre/%post/%preun/%postun. After this change it'd be good to have some kind of temporary exception to be granted before those packages could add a scriptlet back (post F31 work). | |||
Almost all of the hard work is already done, as rpm can react to files being dropped in specified places with known actions (Eg. In this way systemd components can create users or files). There are a few minor changes needed to packages to move from the old way of doing things (Eg. calling adduser) to doing the new thing. Note that while a program will still be run at installation time, those programs will be few and easily audited (as against the 666 slightly different ways of adding a user we currently have). | |||
<!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | <!-- Expand on the summary, if appropriate. A couple sentences suffices to explain the goal, but the more details you can provide the better. --> | ||
| Line 65: | Line 65: | ||
== Benefit to Fedora == | == Benefit to Fedora == | ||
At the moment all of the packages with scriptlets (and anything installed with them) are basically opaque programs that happen to also carry files that are installed, from all of the packaging tools (rpm, ostree, composer, etc.) . After this change the entire installation of the main container image will be declarative, and thus. understandable by all of those tools. This should make things faster, and allow new optimizations | At the moment all of the packages with scriptlets (and anything installed with them) are basically opaque programs that happen to also carry files that are installed, from the point of view of all of the packaging tools (rpm, ostree, composer, etc.) . After this change the entire installation of the main container image will be declarative, and thus. understandable by all of those tools. This should make things faster, and allow new optimizations and features. | ||
This should also make packagers life easier in the long term, as packaging becomes less unique. | |||
<!-- What is the benefit to the distribution? Will the software we generate be improved? How will the process of creating Fedora releases be improved? | <!-- What is the benefit to the distribution? Will the software we generate be improved? How will the process of creating Fedora releases be improved? | ||
| Line 97: | Line 99: | ||
== Scope == | == Scope == | ||
* Proposal owners: | * Proposal owners: | ||
* * James Antill | |||
* * * needs to get combine.d into the distribution, and then /etc/shells can use that. | |||
* * * minor wrangling of package owners to tweak specfiles. | |||
<!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | <!-- What work do the feature owners have to accomplish to complete the feature in time for release? Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?--> | ||
| Line 106: | Line 112: | ||
The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | The issue is required to be filed prior to feature submission, to ensure that someone is on board to do any process development work and testing, and that all changes make it into the pipeline; a bullet point in a change is not sufficient communication --> | ||
* Policies and guidelines: We should | * Policies and guidelines: We should work toward only allowing new scriptlets to appear with policy exceptions, in any of the fixed packages. This needs to be done somewhat carefully, and post F31. | ||
<!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | <!-- Do the packaging guidelines or other documents need to be updated for this feature? If so, does it need to happen before or after the implementation is done? If a FPC ticket exists, add a link here. --> | ||
| Line 135: | Line 142: | ||
== User Experience == | == User Experience == | ||
There should be no | There should be no significant difference to users, initially, although package installation should be faster. | ||
<!-- If this change proposal is noticeable by users, how will their experiences change as a result? | <!-- If this change proposal is noticeable by users, how will their experiences change as a result? | ||
| Line 155: | Line 162: | ||
== Contingency Plan == | == Contingency Plan == | ||
Until higher | Until higher level packaging/installation tooling starts to depend on the scriptlets not being present it is always possible to just let those packages which still have scriptlets continue, if it's required. | ||
<!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | <!-- If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "Revert the shipped configuration". Or it might not (e.g. rebuilding a number of dependent packages). If you feature is not completed in time we want to assure others that other parts of Fedora will not be in jeopardy. --> | ||
* Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES --> | ||
| Line 177: | Line 184: | ||
--> | --> | ||
[[Category: | [[Category:ChangeReadyForWrangler]] | ||
<!-- When your change proposal page is completed and ready for review and announcement --> | <!-- When your change proposal page is completed and ready for review and announcement --> | ||
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | <!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler --> | ||
Revision as of 20:09, 1 July 2019
Limit Scriptlet Usage of core packages
Summary
Remove direct scriptlet calls from "core packages" (those that are used to build minimal container image). The packages can still affect changes during installation by placing files in the correct locations to trigger registered external programs.
Owner
- Name: James Antill
- Email: <your email address so we can contact you, invite you to meetings, etc. Please provide your Bugzilla email address if it is different from your email in FAS>
Current status
- Targeted release: Fedora 31
- Last updated: 2019-07-01
- Tracker bug: <will be assigned by the Wrangler>
- Release notes tracker: <will be assigned by the Wrangler>
Detailed Description
Currently we know how to make an installable OS with packages that doesn't require the use of scriptlets, indeed rpm-ostree and others have already done this on a significantly bigger scale. So we plan to remove direct scriptlets from most (if not all) of the packages in the main fedora container image for Fedora 31. This means all four of: %pre/%post/%preun/%postun. After this change it'd be good to have some kind of temporary exception to be granted before those packages could add a scriptlet back (post F31 work).
Almost all of the hard work is already done, as rpm can react to files being dropped in specified places with known actions (Eg. In this way systemd components can create users or files). There are a few minor changes needed to packages to move from the old way of doing things (Eg. calling adduser) to doing the new thing. Note that while a program will still be run at installation time, those programs will be few and easily audited (as against the 666 slightly different ways of adding a user we currently have).
Benefit to Fedora
At the moment all of the packages with scriptlets (and anything installed with them) are basically opaque programs that happen to also carry files that are installed, from the point of view of all of the packaging tools (rpm, ostree, composer, etc.) . After this change the entire installation of the main container image will be declarative, and thus. understandable by all of those tools. This should make things faster, and allow new optimizations and features.
This should also make packagers life easier in the long term, as packaging becomes less unique.
Scope
- Proposal owners:
* * James Antill * * * needs to get combine.d into the distribution, and then /etc/shells can use that. * * * minor wrangling of package owners to tweak specfiles.
- Other developers: N/A (not a System Wide Change)
- Release engineering: #Releng issue number (a check of an impact with Release Engineering is needed)
- Policies and guidelines: We should work toward only allowing new scriptlets to appear with policy exceptions, in any of the fixed packages. This needs to be done somewhat carefully, and post F31.
How To Test
All of the following should provide no output on a standard container:
* rpm -a --qf '%{preinprog}'
* rpm -a --qf '%{preunprog}'
* rpm -a --qf '%{postinprog}'
* rpm -a --qf '%{postunprog}'
* rpm -a --qf '%{pretransprog}'
* rpm -a --qf '%{posttransprog}'
User Experience
There should be no significant difference to users, initially, although package installation should be faster.
Dependencies
N/A (not a System Wide Change)
Contingency Plan
Until higher level packaging/installation tooling starts to depend on the scriptlets not being present it is always possible to just let those packages which still have scriptlets continue, if it's required.
- 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)