On 2025/11/28 11:32, Prasad Pandit wrote:
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?
A common case is an multi-user environment like when ssh-ing to a server
where you might not know that the package is installed. Having a way to
make these more opt-in in a per-user case would be useful.
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.
If we can eliminate the need for such a package, that would be ideal.
But how do we make it more out-of-the-box experience for the users? One
thing I was considering was somehow making these as systemd user/system
service to add to the `~/.bashrc.d` directory, but that would be just
another thing to teach since we can't enable it by default for the user
right? It would at least eliminate the need for a dedicated sub-package
since it could be toggled on-off via systemctl instead.--
_______________________________________________
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
