On 2/25/26 3:08 AM, Ihar Hrachyshka wrote: > On 2/23/26 8:21 AM, Ilya Maximets wrote: >> On 2/20/26 4:58 PM, Ihar Hrachyshka via dev wrote: >>> On 2/20/26 2:31 AM, Frode Nordahl wrote: >>>> Hello, Ihar, >>>> >>>> Thanks for the patch. >>>> >>>> On 2/19/26 23:14, Ihar Hrachyshka via dev wrote: >>>>> It should be possible to produce debian/ files and run package build in >>>>> a separate isolated environment like pbuilder without going through >>>>> complete source tree configuration process that includes running >>>>> `./boot.sh`, `./configure`, and `make` on the build host. >>>>> >>>>> This should shave off some build time and simplify instructions. >>>> The current arrangement was put in place because there was a desire to >>>> not force DPDK as a dependency on self packaging end users of Open >>>> vSwitch on direction of the OVS maintainer [0]. >>>> >>>> Has this situation changed? >>>> >>> Hi Frode, >>> >>> thanks for the comment and the link. >>> >>> I may miss something, but it's not the intent of this patch to remove >>> the ability of end users to build without DPDK. As per the proposed new >>> build instructions, the end user will have to pick the mode: >>> >>> - if they want dpdk, then ./debian/prepare.sh --dpdk >>> >>> - otherwise, ./debian/prepare.sh >>> >>> What the patch changes is it untangles debian control (and copyright) >>> generation from the rest of the build system. >>> >>> Let me know if it does not address your concern. Perhaps Ilya could clarify. >> Hi, Ihar and Frode. > > Hi Ilya, thanks a lot for the reply. > >> This change does not remove the support for building with DPDK, but >> I'd still prefer the current way we build debian packages. I, for one, >> appreciate when a project has a simple way to build packages that doesn't >> require much knowledge of how to build them for a particular platform. >> >> Distribution maintainers are not using it, they have their own systems >> to build packages, power users who knows ins and outs of debian build >> systems can figure out how to build on their own. What remains are users > > I guess I'm in the "power user" camp - yes I can figure it out! :) > > But right now the repo structure requires me to either go with the `make > debian-deb` process (waste of build time) or reimplementing the code that > generates these two files outside of Makefile. Both are not ideal. > > (OK there's another option - giving up on upstream debian packaging - but > it's worse than the other two.) > >> who are not well versed in the debian or rpm package building, for whom >> we're providing a simple-ish make target that does most of the work. >> This includes both the debian-deb target and the rpm-fedora. >> >> The mk-build-deps step is not necessary if the user already has all the >> dependencies installed, or if they install them in any other way >> (the build will also fail, saying which dependencies are missing), in >> which case the build instructions collapse into just: >> ./boot.sh && ./configure && make debian-deb >> which is the ideal situation for the average user, IMO. And it's also >> close to the workflow we have for building rpms. >> >> So, I'd prefer we keep the current way of building, even if it adds 15 >> seconds to the build process as it seems much more user-friendly. > > If you think the current way of building is more user-friendly, we could > keep it while serving alternative ways. Basically, have the make target > call the spun out script I added here. Would it address your concern? > >> Also, AFAICT, this patch moves the control and copyright files out of >> make's control, so they will not be cleaned up automatically, which >> may be a little annoying. > > The primary issue is that the initiating host may be a lean environment > (think barebones, no dependencies, busybox style) while the actual build > is happening in a *separate* (isolated, chroot) environment. This is how > pbuilder works and arguably the right way to build (mostly) *reproducible* > artifacts. > > In such lean environments, with the current mechanism, first one has to > install (some) dependencies to satisfy ./configure (autotools, compiler > and more); then pack the resulting debian/* (which is the same, expect for > the two files); pass the result to pbuilder... which then - again - installs > (all) dependencies and runs "./boot.sh, ..." process again. > > Let me know if a scoped spin-out of the code behind this make target into a > shell script and wiring of the script back into the make target *without > changing anything* in the current docs or CI flow could be accepted.
I suppose, moving the actual build commands (sed/grep) out of the Makefile into a build-aux script should be fine, we have quite a few of those, as long as automake is aware which files are getting generated and from which sources, so it can keep track of make target dependencies and the cleaning things up. One note here tough is since the script will not be part of a public contract with the user, there is no guarantee that it will not change. At the same time, there aren't many reasons to do so. Best regards, Ilya Maximets. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
