tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: wip/adguardhome, wip/packr - request for feedback and import to pkgsrc



W dniu 28.11.2021 o 20:07, Benny Siegert pisze:
+tech-pkg (I hope you don't mind)

On Mon, 22 Nov 2021, Bartek Krawczyk wrote:

W dniu 22.11.2021 o 14:13, Benny Siegert pisze:
do you see any problems with wip/adguardhome? May it be imported to pkgsrc?

It can probably be imported, I just haven't had the time to do it.

I am worried about it not starting with Go 1.17. Did you report this
upstream? What happens when you do build it with 1.17?


I checked with upstream and they have a target of removing Go 1.16 support with 0.108.x. We're now on 0.106.3 so 2 major versions from now. I'll try to debug it further but maybe you could import it when you have time so we have more eyes looking at it and testing?

I took a close look at adguardhome today, and I am uncomfortable about importing it into pkgsrc. It just seems very brittle.

Two points that I think express this brittleness:

1. The package inherently only builds with a single Go version, due to the way the qtls package does unsafe TLS-related things assuming a certain struct definition. (Never mind that unsafely manipulating TLS-related data seems like a really bad idea!) As a result, this would break each time we upgrade Go versions. At the moment, we remove Go versions as they become unsupported, i.e. we would remove go116 when go118 becomes stable. Having adguardhome in pkgsrc itself would mean that we have to keep it in mind whenever we deprecate a Go version.

2. The way you have to regenerate frontend assets by hand and make a local distfile means additional steps and likely additional breakage.

From my point of view, I would rather keep this package in wip for now. Sorry.

But perhaps one of the other pkgsrc developers has a different opinion?


Do you have any suggestion how to workaround your 2nd point? I took the idea from other package already existing in pkgsrc: www/gitea - it does the exact same thing. I am perfectly fine with generating these artifacts during build but that means downloading npm/yarn packages outside of pkgsrc workflow - are you fine with this?

As for your 1st remark I'll report it upstream.

Regards
Bart Krawczyk



Home | Main Index | Thread Index | Old Index