tech-pkg archive

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

Re: wip/adguardhome feedback and suggestions (was: ALTERNATIVES framework and multiple package versions question)

It is considered best practice for Go code to check in the generated files. You should not need to have packr installed to build. If you do, that's a big that should be reported upstream.


Bartek Krawczyk <> schrieb am So. 24. Jan. 2021 um 13:35:
W dniu 06.12.2020 o 21:40, Bartek Krawczyk pisze:
> Thank you all! It will be arriving - hopefully - this week in pkgsrc-wip.
> On Sun, 6 Dec 2020 at 16:47, Benny Siegert <> wrote:
>> On Sun, Dec 6, 2020 at 12:01 PM nia <> wrote:
>>>> build: client_with_deps
>>>>          go mod download
>>>>          PATH=$(GOPATH)/bin:$(PATH) go generate ./...
>>>>          CGO_ENABLED=0 go build -ldflags="-s -w -X
>>>> main.version=$(VERSION) -X$(CHANNEL) -X
>>>> main.goarm=$(GOARM)"
>>>>          PATH=$(GOPATH)/bin:$(PATH) packr clean
>>>> And I am wondering what is the "pkgsrc way" of building it:
>>>> - should it be corrected with SUBST framework?
>>>> - is allowing "go mod download" a good idea during package build? Or
>>>> should pkgsrc Go modules be used?
>>> It still looks like it's a go program, so it should use the pkgsrc way
>>> to build Go programs and probably not this custom thing?
>>> Yeh, packages shouldn't download files during the build process, they
>>> should all be in distfiles.
>>> I think we're moving away from having go modules in pkgsrc itself and
>>> intead using GO_MODULE_FILES.
>> We have lang/go/ for module-based builds. You can do the following:
>> make show-go-modules >
>> and include that file in your Makefile. Then "make makesum" will make
>> sure all the module files are present and fetched as part of "make
>> fetch".
>> Note that sets up a number of flags and variables so that
>> the build actually uses the downloaded module files. So you will need
>> to fiddle a little bit with the Makefile so that it does that too, and
>> patch out the "go mod download" line.
>> Good luck!

Hi all,
I have commited some initial work on adguardhome package to pkgsrc-wip.
So far it builds but I still have some problems and I need some feedback
and hints.

Based on www/gitea I also added a phase to generate static frontend
files in generate-frontend phase. This uses nodejs + npm to download
dozens of packages. As www/gitea also described this would bypass pkgsrc
fetch phase, hence the split.

- how may I get this archive uploaded to MASTER_SITE_LOCAL? Currently it
is hosted on my temporary web server for testing purpose.

As suggested I tried to simplify the build process and ignored project's
GNU Makefile completely. I tried to replicate their build process by
overriding do-build target. This works fine.
Unfortunately AdGuard Home uses go:generate stanzas:

//go:generate go install -v
//go:generate packr clean
//go:generate packr -z

As I understand it installs packr which also bypasses pkgsrc fetch phase
and I am wondering how to work around this. (PREPEND_PATH you see will
be removed once I figure this out. It is for testing to have packr
available for go:generate).

I tried to add another wip/go-packr package and use
../../lang/ for its installation but haven't been able to
wrap my head around it so far. Since I am no Go developer I've been
reading a lot and checked the source code of Source files also have quite som
import() declarations referencing other remote packages.

- how do you work around something like that? Is supposed
to also take care of all external imports? Should a go-${package} be
created for each such import first?

If packr was installed as build dependency this could be patched to
remove the 1st go:generate line and leave following two as is.

On the positive side: AdGuard Home builds and _runs_ just fine. You can
have a filtering DNS server. An alternative to pi-hole.
On the negative side: I noticed beta versions of AdGuard Home already
changed the build proces...

Does anybody have hints on how to move forward? Once the build process
is ironed out I will of course take care of creating users, setting
directories, permissions, installing start scripts etc.

Probably it is my lack of understanding on the Go build process, but
having multiple places to import external resources (go.mod,
go:generate, import() ) is nice for the developer but a nightmare to
control and maintain.

Bartek Krawczyk

Home | Main Index | Thread Index | Old Index