On Wed, 5 Jun 2019 at 14:58, John Crispin <[email protected]> wrote: > > > On 05/06/2019 14:54, Jonas Gorski wrote: > > Hi, > > > > On Wed, 5 Jun 2019 at 14:33, John Crispin <[email protected]> wrote: > >> > >> On 05/06/2019 13:35, Karl Palsson wrote: > >>> John Crispin <[email protected]> wrote: > >>>> On 05/06/2019 12:17, Karl Palsson wrote: > >>>>> John Crispin <[email protected]> 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 _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
