Package Details: frr 10.3-1

Git Clone URL: https://aur.archlinux.org/frr.git (read-only, click to copy)
Package Base: frr
Description: FRRouting (quagga fork) supports BGP, OSPF, ISIS, RIP, PIM, LDP, BFD, VRRP, NHRP and EIGRP
Upstream URL: https://frrouting.org
Keywords: bgp ecmp isis ospf vrrp
Licenses: GPL2
Conflicts: babeld, quagga, quagga_cumulus
Provides: quagga, quagga_cumulus
Submitter: k0ste
Maintainer: k0ste
Last Packager: k0ste
Votes: 16
Popularity: 0.088366
First Submitted: 2017-02-04 15:24 (UTC)
Last Updated: 2025-03-18 06:02 (UTC)

Latest Comments

1 2 3 4 5 6 7 Next › Last »

cyqsimon commented on 2024-08-08 06:00 (UTC) (edited on 2024-08-08 06:39 (UTC) by cyqsimon)

@Frankkkkk Thanks for the great work.

Edit: it seems like dependencies declared with version restrictions (e.g. libyang<3.0.0) do not work with provides entries (e.g. provides=('libyang')). So I guess this should be done instead:

diff --git a/PKGBUILD b/PKGBUILD
index b1a318d..8b772f8 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -9,7 +9,7 @@ arch=('x86_64' 'aarch64' 'armv7h')
 url="https://frrouting.org"
 license=('GPL2')
 depends=('libcap' 'libnl' 'readline' 'ncurses' 'perl' 'pam' 'json-c' 'net-snmp'
-    'rtrlib' 'libyang>=2.1.128' 'libunwind' 'c-ares' 'protobuf-c' 'pcre2'
+    'rtrlib' 'libyang2>=2.1.128' 'libunwind' 'c-ares' 'protobuf-c' 'pcre2'
     'lua53' 'sqlite')
 makedepends=('gcc' 'bison' 'perl-xml-libxml' 'python-sphinx')
 checkdepends=('python-pytest')

Frankkkkk commented on 2024-06-18 13:14 (UTC)

BTW: I've published libyang2 https://aur.archlinux.org/packages/libyang2 which is fixed to the latest 2 SO. It's an alternative to the current broken libyang and makes frr work :-)

Thanks k0ste!

vecino commented on 2024-04-16 12:20 (UTC)

FRR isn't just about BGP ... it has versatile uses. Don't think for the user. I have nothing more to add. Thanks for your time.

k0ste commented on 2024-04-16 12:09 (UTC)

If you use the AUR repo and service it like I do, for example YAY - https://github.com/Jguer/yay, then pacman https://wiki.archlinux.org/title/pacman is still used and I set IgnorePkg=libyang in it so it doesn't force me to update libyang to a new version. If the user doesn't know this, then FRR can break it and I'm pointing this out to you.

If a user appears who will configure a BGP router and build packets on the same router by some manager, and at the same time he does not know what he is doing, then these are the personal problems of this person and/or the problems of his employer. I can’t imagine anyone doing this, much less rolling out packets to a router without prior testing

vecino commented on 2024-04-16 11:46 (UTC)

@k0ste Slack - https://frrouting.org/community/

If you use the AUR repo and service it like I do, for example YAY - https://github.com/Jguer/yay, then pacman https://wiki.archlinux.org/title/pacman is still used and I set IgnorePkg=libyang in it so it doesn't force me to update libyang to a new version. If the user doesn't know this, then FRR can break it and I'm pointing this out to you.

k0ste commented on 2024-04-16 11:32 (UTC)

@vecino

Precisely because FRR 10.0 cannot be compiled with the new libyang 2.2.8, it is clear that this will cause problems for people who automatically migrate to this version.

Just don't migrate

Watch more Slack frr community. Then you'll be in the loop and know what's going on.

I don't know what is Slack. They can write me on the vk, if wanna

That's why I've disabled libyang updates in my pacman

Don't know what is mean. pacman isn't work with AUR. You can upgrade package if you are not put it into repository

„It should be noted that the libyang developers changed the major version of the SO as it is not backward compatible with the previous libyang v2 release. I believe the recommendation is to have the package named after the SO major version (i.e., so there should be libyang, libyang2 and libyang3 packages)."

If someone want do this work - he can. May be that's you?

vecino commented on 2024-04-16 11:03 (UTC)

k0ste It is not realistic for me to test all FRR demons. I only use OSPFv2 and OSPFv3. I go by what the FRR developers say and they say that the new libyang version broke a lot of things and should not be used. Watch more Slack frr community. Then you'll be in the loop and know what's going on.

Precisely because FRR 10.0 cannot be compiled with the new libyang 2.2.8, it is clear that this will cause problems for people who automatically migrate to this version. That's why I've disabled libyang updates in my pacman. The libyang developers have been unpredictable lately and have repeatedly broken major features, thus breaking the FRR.

btw: chopps is one of the frr dev and wrote to you here: https://aur.archlinux.org/packages/libyang

„It should be noted that the libyang developers changed the major version of the SO as it is not backward compatible with the previous libyang v2 release. I believe the recommendation is to have the package named after the SO major version (i.e., so there should be libyang, libyang2 and libyang3 packages)."

k0ste commented on 2024-04-14 19:39 (UTC)

Can't something break if a user updates libyang to a new version 2.2.8-1? Won't FRR stop working properly then?

@vecino, you can try it and then tell us

vecino commented on 2024-04-14 19:38 (UTC)

k0ste Can't something break if a user updates libyang to a new version 2.2.8-1? Won't FRR stop working properly then?

1 2 3 4 5 6 7 Next › Last »