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

[John Crispin]

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.

     John


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