pfSense » pfSense Packages

We should likely ditch openospfd entirely in 2.1 on. no need for it, Quagga is already a nicer package, doesn't appear to have any of the general openospfd bugs, and having two just confuses people. Definitely warrants a big note in the release notes though since that'll break some people's systems on upgrade.

I thought about making an 'import' feature for Quagga to pull in the config from OpenOSPF since they are so similar. We could also add a tag/feature to the pkg system that could indicate that package A has been replaced by package B, so that during an upgrade or reinstall it will remove A and install B. That would also allow for changing a package's name if needed.

It's unlikely that an import feature would be required - only the most extreme cases would have OSPF configurations so complex they can't be reproduced in five minutes or less. What's more important (IMHO) is updating the package description text to say something like "(deprecated in favour of Quagga OSPFd)" so users have a clue that it's been "pretty much abandoned".
(Which in and of itself is surprising to me, since OpenOSPFd came to exist, in part, because of the low quality of the Quagga implementation!)
Now that 2.1-BETA uses PBI, isn't there a built-in mechanism for stub (or 'transition') packages, i.e. turn OpenOSPFd into an empty package that depends on Quagga? That might not require any changes to the package management front-end...?

Oh, and of course, if the Quagga package does grow an "import" feature, then that's a way to automatically mitigate the breakage-upon-upgrade problem (unless OSPF is required for a default route to the pkg repository, in which case I don't see how you could ever upgrade any OSPFd package without setting static routes temporarily).

we've yet to see a single problem with Quagga's OSPF implementation, and in fact it's fixed scenarios that were having massive problems with openospfd.

An import would be nice, though not strictly necessary, it's easy enough to recreate such configs.

I'd feel more comfortable with an import function, if for no other reason than I can imagine someone trying to do the upgrade remotely while connected to a VPN using OSPF and having it fail to come back up after the reboot. Sure we can put a notice in the release notes and the upgrade guide, but people will still do it, I'm sure. :-)

We can't do any kind of "transition" package the way you describe really, it wouldn't really help anything there. It would just get confusing in the GUI because it would still call itself OpenOSPFD but it would really be Quagga underneath.

I'll see what I can do, at the very least I'll fix the error described here on the ticket and add the note to the package description about its current status.