Modern Perl modules for OpenWrt

For Developers
1

Hi,
for those developing in Perl, I've published some package definitions for modern Perl modules that are missing in the official sources, especially

Net::SSLeay,
IO::Socket::SSL,
IO::Async and
Future::AsyncAwait.

Makefiles can be found here:
https://github.com/jw2013/openwrt-packages/tree/master/packages

Maybe it might make sense to include those in future releases by default?
For my own purposes, I publish compiled binary packages too:
https://jw2013.github.io/openwrt-packages/
(just for 2 platforms atm)

Furthermore, I've developed a UBUS client library in Perl, going to release that soon.
Hope that helps!
Best, -jens

2

You should put your the makefiles up on https://github.com/openwrt/packages/tree/master/lang, then they're made available to all with a simple opkg install or apk add...

2 Likes
3

Thx for the hint! I have not yet submitted to the official repository, just reading the Contributing Guidelines...

4

My first pull request failed in the Test Formalities precheck:
Commit subject line MUST start with ': ' (Common modules for modern Perl development, especially)

I created 10 packages for Perl in total, to cover all dependencies. How shall I submit them correctly, what's the preferred way?

  • One commit for each package, one pull request per commit, in an order to solve all dependencies
  • One commit for each package, but one combined pull request for all 10

?

1 Like
5

@efahl I've created a new pull request with one commit per module, is that correct?

1 Like
6

Should be ok, a few things that might trip it up:

  1. The title usually is package: description, with an optional version prefixing if it's a backport (took me a bit to find where it's documented: https://github.com/openwrt/packages/blob/master/CONTRIBUTING.md#commits-in-your-pull-requests-should). Examples:
perl-modules: add modern networking and process management

[24.10] perl-modules: add modern networking and process management

  1. Typically a PR contains only a single commit, everything is squashed. Not sure how strongly this is enforced, but I've seen the maintainers ask for it many times, so don't be surprised.

  2. Build, testing and PR submission is done first on main snapshot, then backported as appropriate to releases. (Using a cherrypick, preferably but not necessarily, if that's not possible.)

The shear size (11 commits) might make it intractable for reviewers. Be prepared to break it up into 11 different PRs (or whatever makes sense), by grouping the pieces into like-functionality (SSL, async/futures, etc). If one PR depends on another, make sure sure to add that to the PR message.

7

Understood, thank you!
Will have to sumbit them in a specific order, as some depend on others.
The "commit-internal" dependencies look as follows:

  • perl-file-sharedir: perl-class-inspector
  • perl-future-asyncawait: perl-future, perl-xs-parse-keyword, perl-xs-parse-sublike
  • perl-io-async: perl-future, perl-struct-dumb
  • perl-io-socket-ssl: perl-net-ssleay

So for worst case:

Wave 1:

  • perl-class-inspector
  • perl-future
  • perl-xs-parse-keyword
  • perl-xs-parse-sublike
  • perl-struct-dumb
  • perl-net-ssleay

Wave 2:

  • perl-file-sharedir
  • perl-future-asyncawait
  • perl-io-async
  • perl-io-socket-ssl
2 Likes
8

All packages have been merged into master today :grinning_face:

2 Likes
9

Great! Now if you want them in 24.10, you can backport to the openwrt-24.10 branch. Here's more or less what I usually do...

git checkout master
git pull
git log --oneline --no-color | grep 'my commit message'
hash='hash of that commit'
git show --name-only $hash  # Verify it's the right one

git checkout openwrt-24.10
git pull
git branch -c 24.10-my-new-branch
git checkout 24.10-my-new-branch

git cherry-pick -x $hash
git push --set-upstream origin 24.10-my-new-branch
2 Likes
10

Are you sure if that's permitted?
CONTRIBUTING.md states regarding Release Branches:

  • Please ONLY cherry-pick or commit security and bug-fixes to these branches.
  • Do NOT add new packages and do NOT do major upgrades of packages here.
11

It seems to fit bullet point 1.
As to bullet point 2, IMHO it’s not a new package nor a major upgrade, but rather missing Perl modules that work with an existing package.

1 Like
12

Yeah, sort of a gray area here. I'd say "perl" is the real package and these are just adding missing pieces, but the actual devs that manage the package repo might disagree. If you personally want to use them in 24.10, then I'd give it a try, but if not, don't bother.

1 Like
13

I'm going to improve the current packages (descriptions) in the master branch, afterwards I'll try to backport them to 24.10 (which is the platform I use everywhere myself).