>>On 2025/11/27 3:09, Orion Poplawski wrote: >> We have this[1] PR to split out the ccache profile into a sub-package. >> The main package would still have a Recommends on the ccache-profile >> so hopefully most people would not notice a change. >> >> Any other thoughts / perspectives on this? >> >> 1 - https://src.fedoraproject.org/rpms/ccache/pull-request/27
* PR looks confusing. 1. The comment around 'set path = ( @LIBDIR@/ccache $path )' says Use ccache by default and users who don't want it can disable it via environment variable CCACHE_DISABLE. 2. And the reason for sub-package is - to make it possible to not use ccache globally. * Using ccache for recurring compile jobs is useful, so enabling it by default is reasonable. Disabling it and making a sub-package to enable it per user seems an unnecessary step. When CCACHE_DISABLE is available, how does sub-package help? >As someone who also has a sub-package splitting the "enable for all >users" feature, I would also like to figure some naming convention, >approaches, etc. for this kind of sub-packages. I am using `all-users` >in mine. * Should packages be split based on 1 users Vs all users enablement? Generally package is split based on its specific function(s) which are not always required. ex. installing git(1) does not install git-send-email(1). Whether it is used by 1 user or all users, it still needs to be installed before usage. --- -Prasad -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
