nixos/bird: rename bird2 to bird, switch to bird3 by default

[herbetom]

Now that there is a version 3 of bird i think we should cleanup some bird2 stuff and change the default bird package to v3.

In light of that i'm proposing to do a couple of things:

• renaming the current bird package to bird2
• introducing a bird3 package
• having an bird package alias which points to bird3
• renaming the services.bird2 options to services.bird
• introducing a services.bird.package option to allow changing the new bird3 default

I would still keep bird2 around because as of now it seems to have a lower memory footprint and users could be required to adjust their config. And with both versions beeing supported officially (as of now, no word yet how long this will last), we might as well have both for the time beeing to enable a smooth transition.

The bird project has some notes on the migration to v3 here:
https://gitlab.nic.cz/labs/bird/-/blob/v3.0.1/doc/migration-bird3.md

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 25.05 Release Notes (or backporting 24.11 and 25.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[herbetom]

Not sure wheter this should be classified as a significant or a major or breaking change. I would appreciate input in that regard.

[snaakey]

Defaulting to bird3 will break the configuration of some people. I would suggest to default to bird2 for now and throw a warning when the package option is not explicitly set and checkConfig is disabled. So that people get notified that the default package will change in the future and break their configuration if they don't explicitly specify the package.

[herbetom]

@snaakey Thanks for taking a look! Having a check requiring Users to set the package option when checkConfig is set to false sounds like an intersting idea. I'll look into it.

My worry with keeping bird2 as the default is that it's unclear how long both versions will be maintained. Probably long enough for the rather short stable window of NixOS, but still, i would prefer to do the switch for 25.05 and be done with it.
And with us switching from services.bird2 to services.bird it already requires manual intervention by every single user and that should already be quite a warning that something is happening. Switching later doesn't have that same benefit and Users with checkConfig enabled would be less informed that the switch is happening.
Edit: I've extended the info text of lib.mkRemovedOptionModule to also include that there is a switch to bird3.

[SuperSandro2000]

Why not use mkRenamedOptionModule and make package depending on stateVersion?

[fooker]

Using mkRenamedOptionModule is arguable but it can not give a custom user message.
Depending on stateVersion is strange as the user has to handle the change anyways and the added package option seems to be enough.

[CutestNekoAqua]

because its not renamed but actually changed in this case. and having a general services.bird makes more sense in the first place as thats the general practice on nixpkgs in general, this is just bikeshedding imo and preventing useful things from happening on nixpkgs.

[SuperSandro2000]

Depending on stateVersion is strange as the user has to handle the change anyways and the added package option seems to be enough.

If we are using mkRenamedOptionModule and depend on stateVersion then a user doesn't have to do anything immediately and things just continue to work.

If we do it like the current proposal, any user using any of bird has to rename everything and set package to just have their setup continue to work OR migrate to bird3. Both variants are arguable bad in the sight of a "I'll fix the warning later" option.

because its not renamed but actually changed in this case.

No, you're wrong. If we depend on stateVersion like in many other modules eg: nextcloud or postgresql then there is no change.

having a general services.bird makes more sense in the first place

Yep but that is not my point.

[herbetom]

No, you're wrong. If we depend on stateVersion like in many other modules eg: nextcloud or postgresql then there is no change.

If we were to just pin the package there still would be changes:

• The name of the systemd service
• The user/group as which it's executed
• the location of the config file

For most Users this probably isn't relevant, but changing those still could break something somewhere.
One could now attempt to pin all of those values to the stateVersion but that appears to me like enormous complexicty and a testing and validation nightmare going forward.

[herbetom]

Depending on the stateVersion also has the drawback that in a fleet of old as well as new systems i would find it unexpected that with the same config (and stable release) one system runs one major version and another the other.
And with bird config i would find it highly likely that users will share config between multiple systems but since config in most cases probably validates with both versions issues may be quite subtle.

[snaakey]

Edit: I've extended the info text of lib.mkRemovedOptionModule to also include that there is a switch to bird3.

I think this should be enough.

[herbetom]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 366190

---

x86_64-linux

✅ 1 test built:

• nixosTests.bird

✅ 2 packages built:

• bird2
• bird3

[herbetom]

@snaakey Having a check requiring Users to set the package option when checkConfig is set to false sounds like an intersting idea. I'll look into it.

I'll thought about it again and i think for now we don't need such a check. It's added complexity and during debugging it is sometimes quite helpful to disable it shortly. But since i don't expect the "bird3" default to change anytime soon again it seems unncesary to enforce setting it now already.
But i think if there ever is another major change (bird4 or whatever) it's worth considering to introducing something along those lines then.

[SuperSandro2000]

Depending on stateVersion is strange as the user has to handle the change anyways and the added package option seems to be enough.

If we are using mkRenamedOptionModule and depend on stateVersion then a user doesn't have to do anything immediately and things just continue to work.

If we do it like the current proposal, any user using any of bird has to rename everything and set package to just have their setup continue to work OR migrate to bird3. Both variants are arguable bad in the sight of a "I'll fix the warning later" option.

because its not renamed but actually changed in this case.

No, you're wrong. If we depend on stateVersion like in many other modules eg: nextcloud or postgresql then there is no change.

having a general services.bird makes more sense in the first place

Yep but that is not my point.

[herbetom]

@SuperSandro2000 Posting the same reply twice is a really strange move. Was that intentional? I replied to you here: #366190 (comment)