feeds: add freifunk feed

[SvenRoederer]

@jow- @nbd168 @hnyman @blogic

Readd the freifunk packages, that have been moved from the LuCI feed into its own feed in January 2019.
See: openwrt/luci#2533

[aparcar]

Will this be automatically be picked up by the BuildBots?

[SvenRoederer]

just had a short look on the phase2-buildbots and it seems they use the feeds.conf.defaults. So it seems the packages will be build.
Most of them are used by our firmware, so I expect no major failures.

[aparcar]

Are these packages then used by the Freifunk build system? If not are you planing to migrate it over? I think few people would use a subset of packages if they could use a prebuild Freifunk image instead, but I might be wrong.

[SvenRoederer]

Many communities use the Freifunk-Gluon based firmware, which is not using LuCI at all. But there are still some alternative variants around, using these packages actively.
Not sure how many people will use prebuilt packages in place of prebuilt firmware images.
When creating this PR I did not have the buildbots in mind and the ressources it will take, even it should not be so much.
As I'm not aware of any complains that the prebuilt packages have gone, very likely nobody is using them at all and relying on individual community builds. Reconsidering this, it might be more effective just to add this feed commented out, for reference.

[hnyman]

it might be more effective just to add this feed commented out, for reference.

Adding it disabled / commented out sounds much better than forcing all of us to download also that packages feed by default to our own build systems, have definitions related to that feed in our .config files etc, and to have the buildbot crunch the packages regularly.

Adding it commented out would profide a starting reference for those who use the Gluon downstream add-ons, but would not pollute everybody here. ;-)

[adschm]

Just note that (if I understand this correctly), the freifunk feed was cut out of the luci feed, so it's not like this is supposed to be added, but it's supposed to be added back. So, no additional pollution, just the existing stuff.

So, the question to answer is whether this is less relevant than some random niche package from openwrt/packages, then have it commented out. If not, we can as well add it regularly. (I didn't see any stuff that would touch kernel symbols, so no need to add it, though ...)

[bobafetthotmail]

Just note that (if I understand this correctly), the freifunk feed was cut out of the luci feed, so it's not like this is supposed to be added, but it's supposed to be added back. So, no additional pollution, just the existing stuff.

Adding to the above for the sake of maximum clarity:

The packages in that feed https://github.com/freifunk/openwrt-packages are all arch-independent scripting (either shell or Lua) as they are Luci packages, so the build bots aren't really weighted down or anything. It's just a packaging job.

I don't think there is a strong reason for adding the feed commented or rejecting them entirely.

[adschm]

Technically, one of the downsides is that the feed is "out of our control", but that's effectively also true for openwrt-routing, and there is no way to do real harm.

So, I think it should go in as-is.

[aparcar]

Technically, one of the downsides is that the feed is "out of our control"

I remember some tries to move openwrt-routing into openwrt/routing, so maybe another externally managed repositories is a step back...?

but that's effectively also true for openwrt-routing, and there is no way to do real harm.

Is it possible to provide a "fake" newer version of something, which is then offered to all OpenWrt device because the version is higher than in the official repo? If the packages are barely used or recompiled by gluon anyway, few people would monitor the freifunk repo...

Would it be possible to move more packages from gluon over into the freifunk repository and integrate it into their build system? @NeoRaider ? In that case I'd say it makes a lot of sense to add it :)

[bobafetthotmail]

but that's effectively also true for openwrt-routing, and there is no way to do real harm.

Is it possible to provide a "fake" newer version of something, which is then offered to all OpenWrt device because the version is higher than in the official repo? If the packages are barely used or recompiled by gluon anyway, few people would monitor the freifunk repo...

Afaik you cannot override like that the packages in OpenWrt core repo as they are always loaded first in the build environment, while to override packages from other repos you need to place your repo line before their line in feeds.conf.defaults.
Or at least this works with my local package folder, I can copy-paste the whole folder of a package in my "local packages folder", and if I put its line as first in feeds.conf.defaults I can override any package from repos, but not core packages.
For example now aria2 has "HAXX download utility" description in my make menuconfig, so I know the system has loaded my (very evil) makefile for it, not the one from Packages repo.

So it's not a problem if the only repo not controlled by OpenWrt is the last one. Once you get more than one, then yes there is a chance one mught override the packages in the other for fun and profit.

[neocturne]

Hmm, I can't find anything regarding the precedence among the different feeds right now, but overriding core packages is not allowed by default (this is only possible using feeds install -f).

[SvenRoederer]

The intention of the repo-split was to offload some work from the LuCI maintainers and put the control of the "small Freifunk island" to the Freifunk-team. So adding the freifunk-feed is just keeping the bridge to the moved over packages.
This Freifunk-feed is exclusively designed to host freifunk-related packages. Generic stuff should not be there, so I don't expect package-clashes.

@aparcar @NeoRaider I think I talk the the gluon team on adding their packages to the freifunk-repo, when the gluon-community-packages feed (https://github.com/freifunk-gluon/community-packages) came up. But I don't remember the exact reason why this wasn't integrated.

[diizzyy]

I second @hnyman suggestion, this only useful for a very small portion of users however if we look at a wider scale why/which 3rd party repos should be added on which basis (I can see this turning into a mess quickly)?

Pretty sure there's no intended "overlay" functionality regarding packages.

[SvenRoederer]

Just force-pushed an updates commit, which adds the feed commented out.

[adschm]

@SvenRoederer So, if you are fine with the commented variant, I'd merge that one as a compromise between the views expressed here?

[SvenRoederer]

@adrianschmutzler sure, I'm fine. That's why I updated the PR.

[bobafetthotmail]

I don't understand the point of adding a commented feed.

If to enable it I have to edit the feeds.config anyway what's the difference between that and nothing, most people won't ever see those packages unless they know from the start what they want and edited that file.

It really feels like a compromise for its own sake, but without much purpose.

To me it should either be all in or all out. Yes, I think in absolutes.

[adschm]

@NeoRaider Do you have an opinion here?
yes or no or commented?

[neocturne]

I'm fine with it either way.

[adschm]

You made it quite hard for me, but I think @bobafetthotmail has a point in either saying yes or no.

The result of the discussion here seems about 50:50. Since this has been in luci feed before, and I have a weak preference for adding it, I decided to add the feed (uncommented) now.

Thanks for the effort and the discussion.

[SvenRoederer]

Thanks for getting this closed, even not all are happy.