From: Scott Weaver on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/3870#note_2516396416 Yeah, if you were to interrupt this then it would require you to run `git restore priority.rhel` to fix it. If this is kept then maybe I should print out a warning if I see that this file is still modified when building configs. I debated a long time about how to handle this and I thought about creating a `priority.automotive` file instead. I would have preferred creating the separate file but then we'd have to treat it like a flavor and the last time we discussed that it was decided that creating another flavor wasn't the solution. In general, we've been trying to treat automotive like a variant but it's really not. There's no reason to carry all of the configs in the srpm and it's faster for someone interested in automotive if we skip generating all of the configs. Which is part of the reason why I modify the priority file. The real issue is that when we move all the packages from `kernel` to `kernel-automotive` then the configs are expected to be `kernel-automotive` as well and also we don't want to generate the automotive variant of kernel-automotive (which gives us something like `kernel-automotive-6.15.0-x86_64-automotive.config` which is weird). Not only do we get this weird variant of itself, if we only change the package name then the stock kernel's config would look like the kernel-automotive config and it wouldn't actually be the right config (kernel- automotive-6.15.0-x86_64.config). kernel-automotive is it's own package and `kernel-6.15.0-x86_64-automotive.config` is not it's config. That is the config of the automotive variant of the stock kernel package (which we never build along with the stock kernel). So in the end, I left the ugly modification of the priority file so that we generate only the configs we're interested in and nothing else and they have the correct naming convention. -- _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/kernel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
