From: Prarit Bhargava on gitlab.com https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1757#note_945045363 >I quickly took a look at the state of things after this patchset and noticed a few odd things I thought I mention; some or all of them are from before this patchset, but with all the changes you are doing maybe you are interested in these comments. I can file separate issues for any items raised here if you are interested, too. Filing issues would be helpful. If you can, please @ notify me in those issues. > >* is there a specific reason why kernel-ark is using the first 15 characters of the commit-id for snapshot naming instead of just 12 characters, as typically used by kernel developers upstream? I ask as I ran into failures like `5.18.0-0.rc0.20220401gite8b767f5e04097a.15.vanilla.1.fc36.aarch64 exceeds 64 characters` with my vanilla builds. Seems the `20220401git` part is gone after these patches which would solve this for me, but I'd say being more in line with what upstream typically does would be nice. @dzickusrh requested future proofing of this field. I have no issue with changing this back to the current linux standard 12-characters, however, there is some merit into his thoughts for the future. @dzickusrh, counter thoughts? I'm completely open to both viewpoints. > >I also looked at the generated kernel.spec for fedora and noticed a few things that sill look odd, so I'll quickly mention them as well: > >* Is a `%define kversion 5` worth it if `kversion` is later just used once? To answer your question: Nope. It isn't worth having the kversion define. The explanation here is that my effort has been to first target the redhat/Makefile and to clean it up and the scripts the Makefile calls. I will be looking into cleaning up the spec file but a first step here needed to be to better understand how internal variables (defined in redhat/Makefile) and variables available to users (defined in redhat/Makefile.variables) are consumed in the spec file. FWIW: When I asked a similar question a few months ago, no one could give me an answer. What I've tried to do is to at least reorganize the Makefiles so that we can understand that part of process of creating an SRPM in the kernel-ark repo. And :) from you questions which are about the kernel spec file and NOT THE MAKEFILE :) :) it seems like I've done at least a halfway decent job. :) > >* This whole section looks odd too me: >``` >%define specversion 5.18.0 >%define patchversion 5.18 >%define pkgrelease 0.rc6.47.test >%define kversion 5 >%define tarfile_release 5.18-rc6 ># This is needed to do merge window version magic >%define patchlevel 18 ># allow pkg_release to have configurable %%{?dist} tag >%define specrelease 0.rc6.47%{?buildid}%{?dist} > ># ># End of genspec.sh variables ># > >%define pkg_release %{specrelease} >``` > >Having both `pkgrelease` and `pkg_release` with slightly different contents for example is confusing. And why are we defining `specrelease` just to assign it to `pkg_release` a little later? And there is so much redundancy here, if someone wants to change the spec file directly downstream (say from a SRPM) this gets hard. Completely agreed. It's something I noticed and plan on targeting in a future change. I very much dislike those similar variable names. > >To illustrate what I mean: shouldn't the section above maybe look more like this (untested! just for illustration!)? > >``` >%define kversion 5 >%define patchlevel 18 >%define patchversion %{kversion}.%{patchlevel} >%define specversion %{patchversion}.0 >%define pkgrelease 0.rc6.47.test >%define tarfile_release %{patchversion}-rc6 ># ># End of genspec.sh variables ># > >%define pkg_release 0.rc6.47%{?buildid}%{?dist} >``` Great idea :) I've been thinking about how to reorganize and clean this all up, but I wanted the Makefile cleanup completed first. > >Still not nice and definitely won't cover quite a few use cases, but as I said: I just wanted to illustrate how things could look a bit easier to understand in the resulting spec file. I understand and feel the frustration in this comment <- not meant to be a joke. I mean that very seriously. I have found myself very frustrated by the redhat/Makefile and spec file when making *minor* changes, or trying to understand the overall NVR naming convention used in the spec file. I hope I've at least started us on a path to making all of this better for everyone to understand and contribute future changes to. _______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
