[RFC]routing: merge openwrt-routing/packages

[aparcar]

Following the discussion at openwrt-routing/packages there is a majority
in favor to merge the two repositories0. The reasonable doubt of
@bittorf1 (notification bloat) is solvable by using a CODEOWNERS2
file, allowing individual notifications on specific folders.

This eventually unifies things belonging together, adds more eyes to the
routing packages, introduces automatic pull requests testing and even
removes a line from feeds.conf!

Signed-off-by: Paul Spooren mail@aparcar.org

[BKPepe]

There is a lot of packages in net already. What about to create a new folder routing?

[aparcar]

There is a lot of packages in net already. What about to create a new folder routing?

That was my first intention, but then I saw a package from routing to /net here. However I'm fine with both.

[aparcar]

Thanks to CI we found the first error!

make[1]: Entering directory '/home/build/build_dir'
make[2]: Entering directory '/home/build/openwrt_packages/net/cjdns'
WARNING: PKG_MIRROR_HASH is missing, set to 2bcf168b48faab8352db95f85a664adf733554ccc8ea788f1689385b1e7acecb

[adschm]

I'd also prefer a separate folder "routing", although I have no voting right here.

[adschm]

What will happen to the stable branches? Will they stay in openwrt-routing or will they moved to openwrt/packages later in the process?

[BKPepe]

While you would like to merge packages from openwrt-routing, I suggest look what are you going to merge, because Makefiles has stylistic and formal issues.

• PKG_MD5SUM is old, nearly deprecated. Use PKG_HASH.
• Missing PKG_LICENSE_FILES
• Remove MAINTAINER from define Package/foo/Default
• Some Makefiles also includes luci packages. It can be good if you can split it.
• Confusing use of indentation
• URLs of the websites or even as a source can use HTTPS instead of HTTP
• Keep things in Makefile in order.
  I'm trying to stick to this template:

PKG_NAME:=
PKG_VERSION:=
PKG_RELEASE:=

PKG_SOURCE:=
PKG_SOURCE_URL:=
PKG_HASH:=
PKG_BUILD_DIR:=

PKG_MAINTAINER:=
PKG_LICENSE:=
PKG_LICENSE_FILES:=
PKG_CPE_ID:=

[jow-]

I'm only fine with a new folder routing if existing packages get moved into it as well. Otherwise just distribute the former routing packages into the various existing subdirectories (I suppose most will end up in net).

[aparcar]

@BKPepe good points, however I don't see myself reworking all packages just now. I'd be in favor to merge them and then discuss package specific changes case by case. This PR would explode if we discuss all packages of routing (as yes, many of them are outdated).

@jow- I'd be in favor for net and later clean up Luci like packages and such.

I wan't this PR as a clean cut of openwrt-routing/packages, individual fixes in future PRs

[BKPepe]

If nobody does it now, then most probably it won't be done later.

[aparcar]

If nobody does it now, then most probably it won't be done later.

I don't think so, I see many active maintainers helping to fix up Makefiles! Postponing the merge due to modifications likely causes changes in the old repo which would then be ported to this PR and so on.

[feckert]

I think that's a good suggestion.

If nobody does it now, then most probably it won't be done later.

I think we should move the package step by step and fix the Makefile problems on pullrequest creation before merge.
The past has showen if we do not fix the issues now then it will be forgotten and will probably never fixed
Some packages must also go to luci.

[cotequeiroz]

If nobody does it now, then most probably it won't be done later.

How about we share the load, doing them after this is merged?
There are 32 packages. We count the number of volunteers, and divide the packages in alphabetical order--but package maintainers may do their own. I can be the first volunteer.

[neheb]

I usually do so when updating packages. Looks like cjdns needs to be the first. Turns out the tests also need an @!arc dependency.

In any case, I feel this is overdue. The routing repo has no CircleCI or any formal validation.

[champtar]

Hi all,

Do we want to keep the history ? (with some git magic like --allow-unrelated-histories & subtree)
I personally would say yes, we just need to check if it breaks any script with a repo with 2 ancestors

[adschm]

@champtar I've just tested a way to retrieve package history folder-wise and create an examplary merge PR here for babeld:
#9408
With this one could keep history, however all of it would be just put on top of the current state of the packages repo.
This is just meant as an idea (it cost me just about 20 min.), if you don't like it, just delete the PR again.

[champtar]

see #9419 for full history import

[aparcar]

I'll close this issue in favor of individual package transfers with cleaned Makefiles.