[dev] Package discussion & Init scripts

[David Lamparter]

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.