On Wed, 5 Jun 2019 at 15:28, John Crispin <j...@phrozen.org> wrote: > > > On 05/06/2019 15:26, Jonas Gorski wrote: > > On Wed, 5 Jun 2019 at 15:16, John Crispin <j...@phrozen.org> wrote: > >> > >> On 05/06/2019 15:11, Jonas Gorski wrote: > >>> On Wed, 5 Jun 2019 at 14:58, John Crispin <j...@phrozen.org> wrote: > >>>> On 05/06/2019 14:54, Jonas Gorski wrote: > >>>>> Hi, > >>>>> > >>>>> On Wed, 5 Jun 2019 at 14:33, John Crispin <j...@phrozen.org> wrote: > >>>>>> On 05/06/2019 13:35, Karl Palsson wrote: > >>>>>>> John Crispin <j...@phrozen.org> wrote: > >>>>>>>> On 05/06/2019 12:17, Karl Palsson wrote: > >>>>>>>>> John Crispin <j...@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@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
