Re: [gentoo-dev] rfc: add-on files handling improvements

[Thomas D.]

Hi,

William Hubbs wrote:
> I believe, back in the day we started this practice, portage did not
> support --newuse or --changed-use, so there was no way to only update
> packages that had changed or new use flags. In that situation, I
> understand why we installed all of these add-on files unconditionally
> and told users to use INSTALL_MASK if they wanted them not to be on
> their systems.
>
> However, I feel that we should update our practice now since we have these
> features available to us and to our users.
>
> In my previous thread about zsh, it was suggested that I could use the
> zsh-completion use flag to control zsh-completion installation, and not
> rdepend on zsh. This is now how pybugz is set up.

Are we talking about an actual problem?

Are these "add-on files" causing real problems?

How many "add-on files" on an average system are really useless (=cruft
files) for most people and how much disk space do they take up?


Do you remember the discussion about "USE flag per init system"? It was
decided to drop the systemd USE flag if it is only controlling the
installation of systemd service files and we didn't want to introduce a
USE flag per init system because it doesn't scale.

Also, image you are on OpenRC and decide to switch to systemd. If we
wouldn't install the service files on every system the user would have
to re-emerge his/her whole system to switch.

Following your argumentation we would add an exception for init systems.

So which add-on files are left? Logrotate! Doesn't the same argument
against USE flags for each init system applies to things like logrotate,
too? If not, at least the same argument "if you switch your init system"
applies: If you decide to start using logrotate you would have to
re-emerge your packages just for a 1kb file...

Add another exception for logrotate files? :)

I guess that's not what you want. But do you see the problem? How would
you decide for which files you want to add an exception?

Do you want to discuss with cron users if their cronjobs are add-on
files or not?

Some packages are providing files for logwatch. I don't expect that many
desktop user will use logwatch. But do you want to start a discussion
with non-desktop users if it is worth to re-emerge a whole package for
1kb additional files?

Coming back to my first question: Why do you want to change the current
situation? Are these "add-on files" causing any problems nowadays?

Introducing another USE flag to control what INSTALL_MASK already do
doesn't sound like a good way to go for me.

But maybe I am not aware of a real problem you have with these "add-on
files"...


-Thomas