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

[Jonas Gorski]

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.

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).

We should also sanity check the arguments, as IIRC dashes are actually
not allowed in feed names ;P


Regards
Jonas

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