You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 16, 2021. It is now read-only.
while working on an OpenBSD port I figured out some dependency problems.
First things first:
If you port an application to OpenBSD - I guess it's similiar to other platforms - you need to port
every dependency as well. The port-maintainers does not like something like:
add git / mercurial as build dependency
run go get to download all dependencies as well
install the go application
remove git / mercurial
I saw the ArchLinux port - https://aur.archlinux.org/packages/dename/ - does that, but this is not
the best way. The port maintainers does not have control about its dependencies and could
not fix a build problem, caused by a dependency if the original maintainer does not fix it, what bothers the port maintainers on the other hand.
All those dependencies make a port very hard to maintain, as every dependency must be maintained too. I checked other go ports on FreeBSD and they do the same - http://svnweb.freebsd.org/ports/head/net/syncthing/.
What I suggest is the decrease of dependencies and include small parts of other software directly to create ports that are easier to maintain. Especially if the small parts just call small standard library functions.
Any comments or feedback?
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
while working on an OpenBSD port I figured out some dependency problems.
First things first:
If you port an application to OpenBSD - I guess it's similiar to other platforms - you need to port
every dependency as well. The port-maintainers does not like something like:
go get
to download all dependencies as wellI saw the ArchLinux port - https://aur.archlinux.org/packages/dename/ - does that, but this is not
the best way. The port maintainers does not have control about its dependencies and could
not fix a build problem, caused by a dependency if the original maintainer does not fix it, what bothers the port maintainers on the other hand.
They suggest to port every dependency the application has as well and add these ports as build dependencies.
I started to port lots of dependencies dename has, such as https://github.com/gogo/protobuf/proto and https://github.com/agl/ed25519, and removed old ones since they are part of the go environment, such as https://code.google.com/p/go.net/proxy,
But: dename has also a dependency to https://github.com/andres-erbsen/chatterbox only for creating server keys, which is a single file https://github.com/andres-erbsen/chatterbox/blob/master/transport/transport-keygen/main.go. I think this can be integrated into dename directly, otherwise all dependencies chatterbox has must be ported as well.
All those dependencies make a port very hard to maintain, as every dependency must be maintained too. I checked other go ports on FreeBSD and they do the same - http://svnweb.freebsd.org/ports/head/net/syncthing/.
What I suggest is the decrease of dependencies and include small parts of other software directly to create ports that are easier to maintain. Especially if the small parts just call small standard library functions.
Any comments or feedback?
The text was updated successfully, but these errors were encountered: