[dev] Package discussion & Init scripts

[Jafar Al-Gharaibeh]

+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 at lists.frrouting.org
> https://lists.frrouting.org/listinfo/dev