Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add --write-eclean-kernel-preserved-set option #37

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Flowdalic
Copy link
Contributor

@Flowdalic Flowdalic commented Mar 20, 2023

This options makes eclean-kernel create (or update) a portage user set called 'eclean-kernel-preserved'. Since user sets are automatically part of the world set, this prevents kernels that are preserved by eclean-kernel to be uninstalled by portage via the depclean mechanism.

@mgorny
Copy link
Member

mgorny commented Mar 21, 2023

I don't think this is the right approach. It basically assumes that the PM should remove kernels unless user calls eclean-kernel first, in which case eclean-kernel blocks the PM from removing kernels.

It would really make more sense if emerge marked newly installed kernels as "non-uninstallable", and EK removed these markers in order to unblock removal.

This options makes eclean-kernel create (or update) a portage user set
called 'eclean-kernel-preserved'. Since user sets are automatically
part of the world set, this prevents kernels that a remained by
eclean-kernel to be uninstalled by portage via the depclean mechanism.

Signed-off-by: Florian Schmaus <[email protected]>
@Flowdalic
Copy link
Contributor Author

Flowdalic commented Mar 29, 2023

I don't think this is the right approach.

And I think I agree. However, this approach seems to do the job of preserving installed kernels from --depclean. You only have to

  1. emerge @world
  2. eclean-kernel --num 3 --write-eclean-kernel-preserved-set
  3. emerge --depclean

that is, you should run eclean-kernel prior --depclean so that the dynamic user set is generated. Your proposed solution does not have this requirement. But on the other hand, it would require modifications to portage (if I understand your proposal correctly), and, probably overall require more effort.

While I am not absolutely happy with the approach in this PR, it is a relatively small modification. The only thing that I do not like is the dependency on gentoolkit, but it was the only(?) API I could find to query the package owning a file1.

But overall, I like it, and hence would like to continue with this PR. You are, of course, free to reject it on various grounds. I'd like to know where you stand: Is it, as is, an absolute no-go for eclean-kernel?

1: I was quite surprised that I was unable to find a portage API doing the same. But maybe I missed it?

@mgorny
Copy link
Member

mgorny commented Mar 29, 2023

Yes, IMO it's a no-go. It's counterintuitive and it really doesn't belong here.

@Flowdalic
Copy link
Contributor Author

Let us see if we can find a compromise. Would introducing an eclean-kerne hook, which is passed the preserved and to be removed kernel versions as arguments, be acceptable? Then users, like me, could add something that creates the dynamic portage set in /etc/eclean-kernel/hook.d.

@mgorny
Copy link
Member

mgorny commented Mar 30, 2023

What kind of hook? How would it work?

@Flowdalic
Copy link
Contributor Author

Flowdalic commented Mar 30, 2023

What kind of hook? How would it work?

Lines of code say more than a thousands words: Something among the lines of #38

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants