From Fedora Project Wiki
(→‎How To Test: fix calls to rpm -q)
(Add trackers)
 
(5 intermediate revisions by 3 users not shown)
Line 33: Line 33:
* Name: [[User:james| James Antill]]
* Name: [[User:james| James Antill]]
<!-- 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. -->
<!-- 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. Please provide your Bugzilla email address if it is different from your email in FAS>
* Email: james@fedoraproject.org
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
<!--- UNCOMMENT only for Changes with assigned Shepherd (by FESCo)
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
* FESCo shepherd: [[User:FASAccountName| Shehperd name]] <email address>
Line 43: Line 43:


== Current status ==
== Current status ==
* Targeted release: [[Releases/31 | Fedora 31 ]]  
* Targeted release: [[Releases/32 | Fedora 32 ]]  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
* Last updated: <!-- this is an automatic macro — you don't need to change this line -->  {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}  
<!-- 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  
Line 52: Line 52:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1754666 #1754666]
* Release notes tracker: <will be assigned by the Wrangler>
* Release notes tracker: [https://pagure.io/fedora-docs/release-notes/issue/387 #387]


== Detailed Description ==
== Detailed Description ==
Line 102: Line 102:


* James Antill
* James Antill
* 1 needs to get combine.d into the distribution, and then /etc/shells can use that.
* [[JamesAntill/ScriptletUsage]]
* 2 minor wrangling of package owners to tweak specfiles.
* needs to get combine.d into the distribution, and then /etc/shells can use that.
* Not so 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 121: Line 122:
All of the following should provide no output on a standard container:
All of the following should provide no output on a standard container:


  * rpm -q -a --qf '%{preinprog}' | grep -v '(none)'
  * rpm -q -a --qf '%{preinprog}\n' | grep -v '(none)'
  * rpm -q -a --qf '%{preunprog}' | grep -v '(none)'
  * rpm -q -a --qf '%{preunprog}\n' | grep -v '(none)'
  * rpm -q -a --qf '%{postinprog}' | grep -v '(none)'
  * rpm -q -a --qf '%{postinprog}\n' | grep -v '(none)'
  * rpm -q -a --qf '%{postunprog}' | grep -v '(none)'
  * rpm -q -a --qf '%{postunprog}\n' | grep -v '(none)'
  * rpm -q -a --qf '%{pretransprog}' | grep -v '(none)'
  * rpm -q -a --qf '%{pretransprog}\n' | grep -v '(none)'
  * rpm -q -a --qf '%{posttransprog}' | grep -v '(none)'
  * rpm -q -a --qf '%{posttransprog}\n' | grep -v '(none)'


<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
<!-- This does not need to be a full-fledged document. Describe the dimensions of tests that this change implementation is expected to pass when it is done.  If it needs to be tested with different hardware or software configurations, indicate them.  The more specific you can be, the better the community testing can be.  
Line 185: Line 186:
-->
-->


[[Category:ChangeAnnounced]]
[[Category:ChangeAcceptedF32]]
<!-- 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 -->

Latest revision as of 20:42, 23 September 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

Current status

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
  • JamesAntill/ScriptletUsage
  • needs to get combine.d into the distribution, and then /etc/shells can use that.
  • Not so minor wrangling of package owners to tweak specfiles.


  • Other developers: N/A (not a System Wide Change)
  • 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 -q -a --qf '%{preinprog}\n' | grep -v '(none)'
* rpm -q -a --qf '%{preunprog}\n' | grep -v '(none)'
* rpm -q -a --qf '%{postinprog}\n' | grep -v '(none)'
* rpm -q -a --qf '%{postunprog}\n' | grep -v '(none)'
* rpm -q -a --qf '%{pretransprog}\n' | grep -v '(none)'
* rpm -q -a --qf '%{posttransprog}\n' | grep -v '(none)'


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: Just ship packages with scriptlets, as we always have done.
  • Contingency deadline: N/A
  • Blocks release? No

Documentation

N/A (not a System Wide Change)

Release Notes