https://fedoraproject.org/wiki/Changes/Replace_Anaconda_product_configuration_files_with_profiles == Summary == In Anaconda, we would like to introduce profile configuration files and remove the support for product configuration files. == Owner == * Name: [[User:vponcova| Vendula Poncova]] * Email: <vponcova@xxxxxxxxxx> == Detailed Description == Anaconda allows to change its configuration based on a detected product using [https://anaconda-installer.readthedocs.io/en/latest/configuration-files.html?highlight=default_partitioning#product-configuration-files the product configuration files]. The configuration is chosen based on the <code>inst.product</code> and <code>inst.variant</code> boot options, or the <code>Product</code> and <code>Variant</code> options of the <code>.buildstamp</code> file, or the <code>NAME</code> option in the <code>os-release</code> files. This solution has several flaws: * The detection based on the <code>os-release</code> files will no longer work because of [https://fedoraproject.org/wiki/Changes/Fedora_Linux_in_os-release a Fedora 35 change]. * The <code>.buildstamp</code> file is generated by <code>lorax</code> when it creates is a boot.iso. Therefore, we have to rely on other solutions during the live, dir and image installations. * The <code>inst.product</code> and <code>inst.variant</code> boot options are misleading. Anaconda will run with a different configuration. That doesn't mean it will install a different product. * The configuration has to use a fake product name for its identification if it is not tied to a real product. We would like to redesign the product configuration files to solve these issues. The idea is to replace them with more general profile configuration files: * The profile will be identified by a unique id. * The profile can specify additional options for the automated profile detection. * The profile will be chosen based on the <code>inst.profile</code> boot option, or based on the <code>ID</code> and <code>VARIANT_ID</code> options of the <code>os-release</code> files. For example, Fedora Server uses a configuration from <code>/etc/anaconda/product.d/fedora-server.conf</code>. The configuration can be enforced with the <code>inst.product=Fedora inst.variant=Server</code> boot options. The file contains the following sections: <pre> [Product] product_name = Fedora variant_name = Server [Base Product] product_name = Fedora </pre> After this change, Fedora Server will use a configuration from <code>/etc/anaconda/profile.d/fedora-server.conf</code>. The configuration can be enforced with the <code>inst.profile=fedora-server</code> boot option. The file will contain the following sections: <pre> [Profile] # Define the profile. profile_id = fedora-server base_profile = fedora [Profile Detection] # Match os-release values. os_id = fedora variant_id = server </pre> The full draft of the profile configuration files is provided at: https://github.com/rhinstaller/anaconda/pull/3388 == Feedback == <!-- Summarize the feedback from the community and address why you chose not to accept proposed alternatives. This section is optional for all change proposals but is strongly suggested. Incorporating feedback here as it is raised gives FESCo a clearer view of your proposal and leaves a good record for the future. If you get no feedback, that is useful to note in this section as well. For innovative or possibly controversial ideas, consider collecting feedback before you file the change proposal. --> == Benefit to Fedora == * The installer will use ids instead of names. That will solve the problem with [https://fedoraproject.org/wiki/Changes/Fedora_Linux_in_os-release the Fedora 35 change] and prevent similar issues in the future. * All types of installation will use <code>os-release</code> values to identify the product. We can remove workarounds for boot.iso and Live ISO. * The <code>inst.profile</code> option makes more sense, because it allows to choose a different installation profile. * A configuration, that is not tied to a product, doesn't have to provide a fake product name or id. == Scope == * Proposal owners: Will submit a pull request for the <code>anaconda</code> package. * Other developers: Should be no impact. Anaconda provides configuration files for all Fedora products and the products rely on the automated detection of configuration files. * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: None. == Upgrade/compatibility impact == Test the automated profile detection: # Download and boot the Fedora Server ISO. # The installation is started with the Fedora Server configuration. Test the <code>inst.profile</code> boot option: # Download and boot the Fedora Everything ISO. # Add the <code>inst.profile=fedora-server</code> boot option. # The installation is started with the Fedora Server configuration. == User Experience == * Users will have to use the <code>inst.profile</code> boot option instead of <code>inst.product</code> and <code>inst.variant</code>. * Maintainers of custom product configuration files will have to change their files. == Dependencies == None. == 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 == Documentation == N/A (not a System Wide Change) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
