On Thu, Jul 7, 2022 at 1:00 PM Ilya Maximets <[email protected]> wrote:
>
> On 7/7/22 12:27, Frode Nordahl wrote:
> > On Fri, Jul 1, 2022 at 4:09 PM Ilya Maximets <[email protected]> wrote:
> >>
> >> On 6/29/22 15:52, Frode Nordahl wrote:
> >>> * Update upstream OVS debian packaging to be on par with package
> >>> source in Debian/Ubuntu:
> >>> - Provide a openvswitch-switch-dpdk package that integrates with
> >>> the dpdk package in the distributions so that end users can opt
> >>> into a DPDK-enabled Open vSwitch binary.
> >>> - Provide systemd service files.
> >>> - Provide openvswitch-source package for reproducible integrated
> >>> build of for example OVN.
> >>> - Stop building shared library and subsequently remove
> >>> libopenvswitch and libopenvswitch-dev binary packages.
> >>>
> >>> Co-authored-by: Luca Boccassi <[email protected]>
> >>> Co-authored-by: Christian Ehrhardt <[email protected]>
> >>> Co-authored-by: James Page <[email protected]>
> >>> Co-authored-by: Corey Bryant <[email protected]>
> >>> Signed-off-by: Frode Nordahl <[email protected]>
> >>> ---
> >>
> >> Hi. I didn't thoroughly read the whole thing, but I left
> >> a few comments for a few things I spotted. See inline.
> >>
> >> Best regards, Ilya Maximets.
> >>
> >> <snip>
> >>
> >>> +$(srcdir)/debian/copyright: AUTHORS.rst debian/copyright.in
> >>> + $(AM_V_GEN) \
> >>> + { sed -n -e '/%AUTHORS%/q' -e p < $(srcdir)/debian/copyright.in; \
> >>> + sed '34,/^$$/d' $(srcdir)/AUTHORS.rst |
> >>> \
> >>> + sed -n -e '/^$$/q' -e 's/^/ /p'; \
> >>> + sed -e '34,/%AUTHORS%/d' $(srcdir)/debian/copyright.in; \
> >>> + } > $@
> >>
> >>
> >> It's not a problem of a current patch, but the build target above
> >> doesn't work as expected. The 'copyright' file after these
> >> manipulations is a mess.
> >> Upstream commit 3deca69b08f2 ("doc: Convert AUTHORS to rST") broke it.
> >>
> >> Should be fixed in Ubuntu/Debian as well or is it just a problem of
> >> OVS upstream?
> >
> > Thank you for pointing this out. I'll extend the series with a patch
> > to fix this issue as well as forwarding it to debian/ubuntu.
> >
> >>> +Package: openvswitch-test
> >>> +Architecture: all
> >>> +Depends:
> >>> + python3-twisted,
> >>> + ${misc:Depends},
> >>> + ${python3:Depends},
> >>> +Breaks:
> >>> + python3-openvswitch (<<2.17.2-1),
> >>> + openvswitch-common (<<2.17.2-1),
> >>> +Replaces:
> >>> + python3-openvswitch (<<2.17.2-1),
> >>> + openvswitch-common (<<2.17.2-1),
> >>
> >> Here it says 2.17.2-1. It might not make a lot of sense for
> >> upstream, especially when Ubuntu/Debian will release a new minor
> >> version, this check will become obsolete, IIUC. In any case,
> >> I'm not sure how to correctly maintain that. What do you think?
> >
> > These will be updated to 2.17~ in the next iteration of the patch. The
> > Breaks and Replaces fields are added now as a one-off due to the new
> > package source moving files between packages etc. It helps the
> > packaging system (apt) in handling the upgrade. They do not need to be
> > maintained per version moving forward, they will only be updated if we
> > move files between packages or make breaking changes again in the
> > future. Some more details on this page:
> > https://wiki.debian.org/PackageTransition
> >
> > Since there will be no maintenance required for these fields tied to
> > the upstream version cadence, are you ok with it?
>
> Got it. If there is no maintenance required, then it's fine.
> We'll need to change these versions only if we moved some files
> between 2 different packages or re-worked the packaging in some
> other incompatible way, right?
Yes.
> I also see some scary version 2.13.0~git20200212.15ae9db33-0ubuntu2
> for the openvswitch-common package. :) I guess, it's the same story
> there?
Indeed, we can probably drop that one, I'll check.
> And this one here:
>
> +Package: openvswitch-pki
> +Architecture: all
> +Depends:
> + openvswitch-common (<< ${source:Version}.1~),
> + openvswitch-common (>= ${source:Version}),
>
> This package has .1~ suffix, unlike others. Is that OK? Just trying
> to figure out the reason.
I'm unsure about that one myself, I'll check and either remove or
explain the reason here.
> <snip>
>
> One last thing is that we'll need to squash patches #1 and #3 in the
> end, otherwise build fails if only patch #1 is applied. Alternatively,
> automake can be adjusted to not try to evaluate debian/ directory in
> the first patch and bring it back in patch #3.
I did indeed run into that kind of issue for the first iteration of
the series, however I did correct that in the v2 and it builds
successfully.
Since I want to retain the upstream changelog, what I ended up doing
was to empty the debian/automake.mk file only to mention the
debian/changelog in EXTRA_DIST in patch 1 and then reinstate the
proper automake.mk in #3.
--
Frode Nordahl
> Best regards, Ilya Maximets.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
