On 05/06/2019 15:11, Jonas Gorski wrote:
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
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
[email protected]
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
