Hi Coiby, On Fri, 30 Jun 2023 18:14:34 +0800 Coiby Xu <coxu@xxxxxxxxxx> wrote: > Hi Philipp, > > On Thu, Jun 22, 2023 at 11:54:52AM +0200, Philipp Rudo wrote: > >Hi Coiby, > > > >On Mon, 19 Jun 2023 15:31:27 +0800 > >Coiby Xu <coxu@xxxxxxxxxx> wrote: > > > >> Related: https://bugzilla.redhat.com/show_bug.cgi?id=2121912 > >> > >> Now there is a growing user base to use the kexec reboot and it's > >> desirable to make the kexec-tools package more modular. > >> > >> This patch splits current kexec-tools into two sub-packages kexec-tools > >> and kdump-tools. Now kexec-tools merely provides /usr/sbin/kexec and the > >> remaining features go into kdump-tools. > > > >all in all I'm in favor for this change. But for me simply splitting > >kexec-tools in a separate sub package is just a half-baked solution. > >When you look at the current kexec-tools you see that it consists of > >four different projects. There's upstream kexec-tools, makedumpfile and > >eppic as well as our Fedora tooling. The 'clean' solution would be to > >move each project into it's own package. Ideally each having it's own > >repo which would allow us to move to a source-git based work flow. > > > >Anyway, just my 2 ct's. > > Thanks for sharing your thoughts! Yes, one potential benefit is we can > upgrade kexec-tools, makedumpfile and eppic alone if each package has > it's own repo. I haven't decided to do that is 1) currently only users > request the upstream kexec-tools to be split out and the remaining > things like makedumpfile are only for kdump; 2) I don't how much work I > need to create four standalone packages for example I don't what > procedure I need to go through to apply for a new package. Could you > list other known benefits of "moving to a source-git based workflow" so > we make a decision? The main benefit of the source-git based workflow I see is that you do have access to the source code as it is packaged in a human readable form. In my opinion this makes working with the package a lot easier. For example this is my workflow when backporting, say a makedumpfile patch 1) checkout the version in the upstream repo 2) apply all patches already backported in the correct order to prevent conflicts 3) make the actual backport (i.e. cherry-pick+adjust the commit(s) required, testing etc.) 4) create patches from the commit(s) created in 3) 5) move patches to dist-git and adjust the spec file 6) test again to verify that the patches were actually applied in the spec file In a source-git based workflow all that is needed is step 3). All other steps are automated. An other benefit I see is that reviewing backports is much easier. You simply have a diff that shows you all changes made to the code. Not a diff that adds a patch file which you then have to decode in your head. This might work for simple backports but in complex cases, when there are many conflicts with upstream, there is no other way than manually re-creating the source-git (i.e. steps 1 & 2 from above) so you can actually review. Finally, splitting up the package even further gives us more flexibility to adjust to future developments and gives us options for optimization. Its basically the same reason what Zbigniew asked for kexec-tools but for the other tools. Say a user doesn't use makedumpfiles '--eppic' option. Why should they install eppic? Or the user uses 'scp' to dump to a remote host. Why should they install makedumpfile? That's less important for normal installations, but gets important when you build container images with mkosi [1] and want to optimize them for size. To be fair, there are not that many backports for the package and the last argument is somewhat a bet on the future. Nevertheless, I believe it will be way less effort to split them out all at once rather than one after the other. Thanks Philipp [1] https://github.com/systemd/mkosi _______________________________________________ Anaconda-devel mailing list -- anaconda-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to anaconda-devel-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/anaconda-devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
