+1 On 5/22/2017 11:34 AM, David Lamparter wrote:
Well... let's add my 2 euro-cents. This mail will sound somewhat annoyed, please read further down why I think none of this is productive.
On Sat, May 06, 2017 at 06:38:57PM -0700, Martin Winter wrote:
1) Do we want to use 'vtysh integrated-config' for FRR 2.0 packages ? "Mu." - You're asking the wrong question.
vtysh and the daemons actually autodetect whether an integrated config is in use. The decision is made by what the distro packages and what the admin has on his system. This also means our code should work with both, for now.
We should probably add a deprecation warning if independent-config is in use -- on 3.0. I don't want to touch 2.0 on this anymore.
2) Do we want the packages on each platform as close to each other as possible or do we want it to follow the conventions of each distro as close as possible? The latter, because the distro doesn't package "our" pieces, they create packages according to their own guidelines and rules. It's a huge problem if we distribute packages with the same name, but differing conventions. In fact, if we have packaging scripts in our repo, we should pull in the distro's changes.
Note Debian explicitly recommends *against* having /debian in a release tarball, cf. https://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source Note that they explicitly distinguish git vs. tarball, and we actually are in "compliance" with that since our debian/ dir is not listed in Makefile.am. I would argue the same for redhat/.
Making FRR usage as similar as possible across different OSes is a nice goal, but when we start talking about init systems we're overstepping our boundaries. Linux distros had and still have individual init systems and conventions for 20 years, and LSB and FHS are putting a lot of work into trying to make the world better here. We won't be solving this in a few weeks.
(Neither does systemd, btw.)
I thought about the packages as reference packages for package maintainers to build on (and the merging changes from the back in as far as possible) That's a nice thought, but this is a great example of the road to hell being paved with good intentions. I can promise you 90% of distros will flat-out delete or ignore it.
Each platform has differences in capabilities and guidelines for building them: - Conventions where configs and binaries should be installed - Startup system (init.d, systemd and others) - Configuration location (ie /etc/sysconfig for redhat, /etc/debian for debian etc)
Each system also provides functions and examples for startup scripts.
After this is decided, then I think we can talk about the issues on exceptions There is nothing for us to decide here. Our next action is:
0. make tarballs available for frr 2.0.
I can't believe we don't have a dist tarball up. THIS IS WHY WE DON'T HAVE FRR PACKAGES IN DISTROS. THERE'S NO TARBALL FOR THEM TO BUILD OFF. DISTROS DON'T WANT TO BUILD FROM GIT.
1. put up a README for the distro maintainers on what we're planning to do. IMHO, it needs to say 2 things:
(a) we're moving towards integrated config; right now we're trying to detect and adapt, but at some point this may change. (b) watchfrr may be becoming more important for multi-instance management so we can start ospf #5 on a "router ospf 5"
If we have things we need agreement on here - please start a new thread.
2. wait, talk, wait, and talk to the distros. They'll make FRR packages by copying their Quagga build descriptions. If we have good READMEs and talk to them nicely, we can influence this. If we sit on our asses - or try to dictate what they should do - they'll do what they think is best while ignoring our plans.
So... I think we're deep in bikeshedding land here. The PR with the RedHat changes doesn't matter, because whoever picks up FRR at RedHat is gonna run it over with a lawnmower anyway. Neither do our attempts to unify FRR across distros - they will get the lawnmower too.
To be even more explicit, I am in strong disfavor of even discussing this in yet another meeting (weekly, maintainers or TSC). It's simply not productive. We don't need a decision, because we already went down the wrong path earlier and are now deciding whether we want our highway to nowhere with 4 or 6 lanes.
Sighing,
-David
P.S.: Things being in distro's decision-space pretty sure means neither Martin nor Donald get their cake and eat it.
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev