Allow modifying current defconfig #2
No reviewers
JeremyStarTM
Labels
No labels
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: JeremyStarTM/aur-linux-clear#2
Loading…
Reference in a new issue
No description provided.
Delete branch "yarost12/aur-linux-clear:YF-allow-modifying-current-config"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Allow copying the current config and modifying it by running: _use_current=y _makenconfig=y (or other config modifier).
I do not entirely see the value of this PR here. Wouldn't it be smarter to modify PKGBUILD#312 to simply always invoke
update_defconfig?But then we're just starting off from scratch every time, unless I'm missing something. We can in theory bring out the checks of modify_defconfig, but then we'd still need to check inside of it to know which util to call.
I just want to be able to do the followin:
Also I think you didn't enable landlock correctly, it needs to be added to the CONFIG_LSM list
Wouldn't be it better if that config overriding code would be executed every time? Let's say that our currently running kernel is not linux-clear and we want to use it's current config. Our optimizations and changes will never be applied to that config, which is in some cases bad.
Oh, will take a look at that tomorrow (I'm in Germany btw.)
I'm in the Baltics.
Well, I assume that people using these flags know what they're doing, otherwise they probably wouldn't be touching them. We can add a warning or an info message saying something like
I don't think we should be forcing people to use linux clear flags, maybe they're here for the patches only. I personally always disable SELINUX due to some horrors that I went through getting it to work on the commercial projects.
Never assume that someone knows what they are doing, that can only backfire. If someone knows what they are doing, they will have already looked at the PKGBUILD and removed the fluff that they don't like. And true, we could add a warning, but overriding kernel options is likely always safer. You are guaranteed to get different experience if you are using your current kernel's flags. This is in my opinion something which should not be happening.
Look at it this way: previously, before the #1, we could re-use the old config and modify it. The only difference is that it would go through all the enablings/disablings that are hard-coded and end up being mangled.
This PR restores that functionality but does it more cleanly, we bypass the hardcoded mods and just setup a new config on top of the old one. I think this is a cleaner approach to re-using the old config.
I don't think we should force users to fiddle with PKGBUILD if they want to modify the config that they've already modified. Yeah it's cool and all but maintaining a personal fork (even if it's a local one) is a bit of a pita.
We could meet in the middle: We could make a new configuration option where users can turn on or off overriding some flags and then show them the lines where the overriding takes place. That way users who already modified their config to their heart's content can keep it and users who want to take those overrides with them can enable them.
I am not sure I understand what you're suggesting. We could add a _optimize_defconfig flag to reapply the defconfig modifications. If used in combination with _use_current it would copy the config -> apply modifications -> open menuconfig (if _menuconfig was passed).
Does that sound good? We could make a parser to go config by config but I think that's excessive.
bce10af1e6to5139ded653Sounds good, that's exactly what I meant. Building a parser for this would be way too overkill. I don't think that I have the energy to build a new parser haha
Updated your comment a bit to correct some information. Otherwise lgtm