-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
libyang3 - fondation step 1 #15608
libyang3 - fondation step 1 #15608
Conversation
6db0ecb
to
c68a588
Compare
This pull request is a fondation in order to prepare the followings:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm all in for using libyang3, but I am against all this conditional compilation to support both versions. There's no problem with moving to libyang3 as long as we provide packages in our repositories, as we did when moving to libyang2.
So does it mean that we are ready to have a d-day that switches the libyang versions ? without any overlapping. Frankly, I do agree that it would be simpler and it would enforce a quick alignment for the the CIs, distros, etc. For the packaging of libyang2/3, would you have a good pointer I could start with ? |
That's what we did with libyang2, so I don't think there's any problem with upgrading to libyang3 without keeping compatibility with older versions. Regarding the packaging, I suppose we should just ask @mwinter-osr and @Jafaral to start packaging libyang3. But I don't see yet the official release of libyang3, so we should probably wait a bit until it's actually released. |
For libyang3, there are some ABI changes, so it cannot be a smooth transition. I would like to start before libyang3 will be officially released in order for FRR to set some alignments with libyang3. |
Should we consider adding shims for these apis that may/will change in the future? I'd prefer shims to repeated conditional blocks.
|
This only affects FRR 10.1+, but if it backward compatible with with 10.0, then we can build packages libyang 3 packages and have that available in our package repos. It it doesn't work with 10.0, it is a bit tricky since our stable version is going to be 10.0 for a while, and we can't publish packages to stable if it breaks 10.0. |
We're already publishing both libyang and libyang2 packages at the same time. What's the difference here? It's new packages named |
38c9a53
to
05b0b69
Compare
@idryzhov : enclosed a minimalist changeset based on our discussions and an update of the libyang's.headers. |
the CI/topotests on master with libyang2.2.8/libyang.so.3 is successful on my local setup. |
notes:
|
using the following package, it should not overlap with libyang2, so both libyang3 and libyang2 can be installed:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a testplan for building on the CI:
https://ci1.netdef.org/browse/TESTING-FRRLY3VINCENT
One missing part is the build dependency in debian/control
: It should allow libyang2-dev or libyang3-dev.
Current under `Build-Depends" it lists:
libyang2-dev (>= 2.1.80),
Correct should be:
libyang2-dev (>= 2.1.80) | libyang3-dev,
Please fix debian/control
done @mwinter-osr |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good
one or two line wrap lint suggestions we should probably pull in before merging ... |
Let's support libyang 2.2.8 using libyang.so.3.0.8 It requires the commit ed277585ea from the libyang. Signed-off-by: Vincent Jardin <[email protected]>
libyang3-dev is required. TODO: add redhat, snapcraft Suggested-by: Martin Winter <[email protected]> Signed-off-by: Vincent Jardin <[email protected]>
done @riw777 |
Prepare the support for libyang3 ; do not merge it yet.