[dev] Package discussion & Init scripts

[David Lamparter]

On Mon, May 22, 2017 at 02:18:55PM -0700, Martin Winter wrote:
> 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

My argument is that you're asking the wrong question...

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

So, I've gone to my friendly operator IRC channel of reference and asked
what general opinions are.  I have received the following input:

- yes, people sometimes install project-provided binaries
- if they do, they want a repository, not packages -- so updates
  actually work.
- people make their own repositories with their own modified/custom
  packages if they need to
- people actually convert .deb into other things that fit their distro

That said, the distro's package is still the first source.

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

The only thing /possible/ at this point, IMHO, is a generic package that
doesn't target any specific distro.

This is simply a logical conclusion because we have no idea how exactly
a distribution package for a particular distro and version will look
like, which means we can't be compatible with it, which means we can't
use the same name (because that would create random conflicts when
updating distro<->ours), which means we need to ensure isolation to
avoid f*cking up user's installations.

We can put up our own more-recent packages as soon as a distro has
packages for FRR -- or as soon as we know that there won't be such a
package for the foreseeable future.  The latter is really not the
expected case for FRR.

So, no, I don't think we shouldn't have our own packages for distros up
right now.  We should talk to distros, figure out what their package
will look like so it's acceptable to their rules, and then we can
publish automatically-updated most-recent packages on our own with the
same semantics in our own repo.

[snip]
> >> 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.

No, we don't have anything, because AFAIK we haven't gotten a Debian
maintainer to take up FRR and claim responsibility for it, and start
working on it.

It doesn't matter what Silas has or what we have in git.

What matters is what shows up on:
https://packages.debian.org/search?searchon=contents&keywords=frr&mode=path&suite=stable&arch=any
... which is nothing.

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

Our debian/ directory is not contained in our dist tarballs.

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

You are arguing "why some things we could do are not a problem".

But the question here is "what can we do to get packages in distros".

If you ask that question to a Debian maintainer, and they tell you
"having a debianpkg/ directory in your repo would help us", THEN I will
accept your argument.  But even then I will ask you (or the maintainers)
"what priority is that?"

... and I'm pretty sure first priority is actually talking to them
asking them what /helps/ them.

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

There's a dependency chain here.  We need this README ASAP, before
distros package things differently out of sheer unawareness of our
future plans.

And the distro packages are a dependency for /our/ high-quality
packages.

And at that point this discussion we're having here is obsolete, because
it'll be obvious what works with the distros.

So... I'm still seeing bikeshedding here.

> > 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:
> - 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)

... and which they will customize to fit their own needs.  I'm not
accepting this one.

> - My CI system which uses them for testing
> - The users which currently use my broken frr-test packages from the CI

I worry more about the 99% of users who simply don't see any FRR package
at all, because we're _not_in_their_distro_.

> - Users which come directly to us to look for up-to-date packages

Which we can't address currently because such users would (rightfully)
expect that they can update to our packages/repo from their distro - and
back.  And we can't do that because we don't even know what we should be
compatible with.

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

Yes.  All of them right now, really.

If you really want packages up right now, I would make a generic .deb
and a generic .rpm.  I would NOT call them Debian, Ubuntu, RedHat,
CentOS or anything - in fact I would explicitly label them as
"generic/no distro".

But that's still a secondary priority after talking to the f*cking
distros and asking them what we can do to help them get our packages in.

And just to be explicit - doing random packaging work without asking
them isn't "helping them".  Helping people is asking them what you can
do for them, and then doing that.


-David