[OpenWrt-Devel] [PATCH V3 2/2] script/feeds: add a new command that allows generating a new feeds.conf

[Jonas Gorski]

On Wed, 5 Jun 2019 at 15:28, John Crispin <john at phrozen.org> wrote:
>
>
> On 05/06/2019 15:26, Jonas Gorski wrote:
> > On Wed, 5 Jun 2019 at 15:16, John Crispin <john at phrozen.org> wrote:
> >>
> >> On 05/06/2019 15:11, Jonas Gorski wrote:
> >>> On Wed, 5 Jun 2019 at 14:58, John Crispin <john at phrozen.org> wrote:
> >>>> On 05/06/2019 14:54, Jonas Gorski wrote:
> >>>>> Hi,
> >>>>>
> >>>>> On Wed, 5 Jun 2019 at 14:33, John Crispin <john at phrozen.org> wrote:
> >>>>>> On 05/06/2019 13:35, Karl Palsson wrote:
> >>>>>>> John Crispin <john at phrozen.org> wrote:
> >>>>>>>> On 05/06/2019 12:17, Karl Palsson wrote:
> >>>>>>>>> John Crispin <john at phrozen.org> wrote:
> >>>>>>>>>> This can be used inside build setups for easy feeds.conf
> >>>>>>>>>> generation.
> >>>>>>>>> Could you give us an example of how this is actually easy, or
> >>>>>>>>> what sort of functionality this is providing beyond "cat
> >>>>>>>>> feeds.conf.default feeds.conf.extra > feeds.conf"
> >>>>>>>>>
> >>>>>>>>> It seems like a lot of perl for a narrow usecase.
> >>>>>>>>>
> >>>>>>>>> Sincerely,
> >>>>>>>>> Karl Palsson
> >>>>>>>> This was brought up as a missing feature by the prpl folks. I
> >>>>>>>> considered on how to best implement this and find that having
> >>>>>>>> proper tooling is much better than having to carry around an
> >>>>>>>> extra file that is cat. being able to build the feeds.conf
> >>>>>>>> dynamically like this just seems much cleaner to me and will
> >>>>>>>> allow downstream users, vendors, odms and integrators to have
> >>>>>>>> less need to patch their trees to death.
> >>>>>>> So, they still have to have a script, but now the script has...
> >>>>>>>
> >>>>>>>
> >>>>>>> ...
> >>>>>>> ./scripts/feeds setup -b src-git,private-aa,git://blah
> >>>>>>> src-link,private-bb,/wop/blah
> >>>>>>> ...
> >>>>>>>
> >>>>>>> instead of
> >>>>>>> ...
> >>>>>>> cp feeds.conf.default feeds.conf
> >>>>>>> echo "src-git private-aa git://blah" >> feeds.conf
> >>>>>>> echo "src-link private-bb /wop/blah" >> feeds.conf
> >>>>>>> ...
> >>>>>>>
> >>>>>>> I mean, _yes_ it's "simpler" but it's only simpler by bringing in
> >>>>>>> new tools with new layers of abstraction. I really question
> >>>>>>> whether that's actually simpler for anyone in the long run, and
> >>>>>>> also how this really counts as a "missing feature" There's still
> >>>>>>> going to be a requirement for that vendor script.
> >>>>>>>
> >>>>>>> Sincerely,
> >>>>>>> Karl Palsson
> >>>>>> Its not a new tool, its an extra call to an already existing one. I
> >>>>>> believe that the one liner is much cleaner than the 3 line scriptage.
> >>>>>> there is no requirement for a vendor script. they ship with a PDF that
> >>>>>> has the build steps. This oneline will be much easier to use I believe.
> >>>>> Since the use case is having additional custom feeds to the normal
> >>>>> package feeds, maybe it would make more sense to have a e.g.
> >>>>> feeds.conf.custom that is used as an addition to the
> >>>>> feeds.conf.default instead of completely replacing it. That way you
> >>>>> would avoid missing upstream changes in the feeds.conf.default when
> >>>>> updating your build environment.
> >>>> Hi,
> >>>>
> >>>> The patch does not manipulate the default file at all.
> >>>>
> >>>>
> >>>>> Then we could add a few commands to scripts/feeds for manipulating
> >>>>> that feeds.conf.custom (adding/removing feeds, changing their
> >>>>> types/addresses/names etc).
> >>>> so instead of using script/commands to create the already existing
> >>>> feeds.conf file we should introduce a 3rd file ? that makes no sense to me.
> >>> No, in that case there would be no feeds.conf. Just feeds.conf.default
> >>> + feeds.conf.custom (a "diff"), so still only two files. Different
> >>> name to not break existing feeds.conf setups. Or add a marker to
> >>> feeds.conf to mark it as a "snippet/diff". Or maybe use the include
> >>> thing proposed by Bjørn at the top line of the generated feeds.conf.
> >>>
> >>> So the feeds.conf generated by your command would then be
> >>>
> >>> src-include feeds.conf.default
> >>> src-git custom_stuff git://example.com:foo
> >>>
> >>> avoiding having to have a local, unchanging copy of contents of
> >>> feeds.conf.default in there.
> >>>
> >>> A bit like we split up the opkg feeds configuration to basic/dist
> >>> feeds files and custom feeds file.
> >>>
> >>>
> >>> Regards
> >>> Jonas
> >>
> >> That will yet again require an additional git tree, which is not
> >> deployable inside a tar file + pdf and is voodoo to the users. I do like
> >> the idea though, but it is fitting for a foss developer and not a
> >> corporate coder.
> > ??? Where does the additional git tree come from?
> >
> > If the feeds.conf.default doesn't change, that's fine. But not having
> > the default feeds in a (local) configuration file has the advantage
> > that if you e.g. update your base distribution/sdk from e.g. 19.06 to
> > 19.12, you don't need to update your feeds.conf to point to the 19.12
> > branches. Or re-create it.
> >
> > Jonas
>
>
> ah ok, so i'll modify the patch to not copy the feeds.conf.default to
> feeds.conf but let it reference the file using bjorn's patch

Exactly what I was proposing :)

Eventually we might want to not require to pass all custom feeds at
once to the script, but have a add_feed command (so you can easily add
one at a later time), but that is nothing that affects your proposed
changes, just adds on top of it.


Jonas

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel