Update openwrt custom package apt-cacher-ng to 3.7.4

Not sure if this is the right place. Pointers welcome.

I have been maintaining a fork of apt-cacher-ng as an openwrt package here: https://github.com/vasvir/openwrt-packages

This time around I updated it to the latest openwrt SDK 22.0.3 and apt-cacher-ng 3.7.4

Hope that somebody else find this useful.

Hi vasvir,

thank you for updating apt-cacher-ng to version 3.7.4.
I will test It on 23.05. as soon as possible.

What do you think to bring this package in upstream?

Best regards

Canaindica - a contributer

Hi canaindica,

Good to hear from you again.

I have no objections to try to bring it upstream but I don't know from where to start.

Do you happen to have any links documenting the procedure?

Hi vasvir,

basically just a PR againts the package repo needs to be created. Details of the formal stuff can be found here: https://openwrt.org/submitting-patches .
The question is, do you wan't to be the maintainer of an official openwrt package?



The link you posted is useful and informative but it concentrates on submitting patches. I would like to see a more high level of what it actually means to be an openwrt maintainer especially time wise.

I don't have an objection to some sporadic maintenance from time to time but I can't commit to something that requires a lot of time and most certainly I cannot follow every subrelease.

I will do a bit of research in the weekend.

Hi vasvir,

I think we can stay at one specific version (e.g. 3.7.4) as long as we want.
Ancient sources of apt-cacher-ng are not hosted on the debian servers (see: http://ftp.debian.org/debian/pool/main/a/apt-cacher-ng/ ), but we can retrieve them from their git repo under https://salsa.debian.org/blade/apt-cacher-ng/ using the tag "upstream/<version>" (e.g. "upstream/3.7.4").

I think this approach can obviate the pressure to always have to update to the most recent upstream version of apt-cacher-ng. Hence, we can proceed as we did in the past just doing sporadic updates.

I think having an installable package from a repo even if it is not frying hot is better, than havin none.