[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 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.
> We should also sanity check the arguments, as IIRC dashes are actually
> not allowed in feed names ;P

goodd catch, I'll add that to the patch

     John


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

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