[dev] Package discussion & Init scripts

[Martin Winter]

On 22 May 2017, at 9:34, 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.

I think you answer the wrong question… see below
>
>
> 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.

There are 2 possible different issues here: Distro’s and our packages.
The can (and in a good case should) be similar, but for most OS projects
I see them very different - just for the fact that packages in distro’s
lag behind the development in years.

My believe is to have our own packages up (like many other packages do)
and merge in as much as we can/agree from future distro packages.

> 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.

Different discussion, but I’m open on this (at least for 3.0). Personally
I would prefer some transition script to convert to integrated config.

>> 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/.

First of all, we don’t have debian package infrastructure yet. We have
a start of it as a work-in-progress PR by Silas.
>From my discussion with Debian maintainers, the main issue is that their
build system is using “debian” as a subdirectory during the building
of packages and the issue is because of this (they need to delete it
or merge it or something else and it causes extra work)

Some of them prefer the debian part in separate git which I don’t like
because of the painful version dependency hacks to match one debian
script dir with a specific frr git.
An acceptable workaround (as confirmed by multiple debian folks) is
to call the directory anything else - i.e. “debianpkg”.
This could then be part of the release tarball with no issues.

Redhat has no such issues as there is no reserved “redhat” directory
name. So I see no problem to have this part of the release tar ball.

> 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.

Their choice and our influence is probably limited. But I was told that
as further away it gets from Quagga (i.e. more work for them to just change
the Quagga package) makes it more likely for them to at least have a good
look at our package scripts.
But they ultimately make their own decision and they have to “support”
it in some way.

>> 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.

I see this as a different PR and welcome anyone trying to do this.

> 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.

It matters for multiple folks:
- The users which currently use my broken frr-test packages from the CI
- Various SDN/Whitebox distros (ODL, OpenSwitch etc) which build based on
  OUR package directories (no, they are NOT ignoring them unless they need
  to fix/change them)
- My CI system which uses them for testing
- Users which come directly to us to look for up-to-date packages

I see no bike shedding here - I see different discussions.

> 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.

So you are proposing to NOT provide any packages for specific Distros?

And yes, I want this on tomorrows meeting to see how to proceed.

- Martin

> P.S.: Things being in distro's decision-space pretty sure means neither
> Martin nor Donald get their cake and eat it.

Or you could ignore the distro cake if you don’t see a need and let everyone
else have the option for it.