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.
Thanks,
Ihar
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
