First time (trying) to create a port I need guidance

Good news, Claude (the AI thing) was finally able to convert to GO script into a [/icode]shell[/icode] script, that compile the libraries and the binary and copies all the artifacts in the right places.

I am going to run further test and then I will work on create the port.

I hope I am not infringing any rules by using a LLM assistant to create this port... 🤔
 
The shell script works and it passed all the tests!!!

I can focus on the port now.
 
Claude created all the files necessary.
Now I can run make stage, make install, make deinstall and everything works fine... 🙏

I guess now I should submit it, I need to read again the manual cause dealing with these AI really stressed me out a lot...
 
Hi guys,

so far I managed to create the rules for built the development cycle, but this software comes in stable and development; I wonder if I should create a different binary for each version or place a rule that if you use stable you cannot use devel, and therefore one uninstall the other.

What's your opinion on this?
 
mrd said:
but this software comes in stable and development; I wonder if I should create a different binary for each version or place a rule that if you use stable you cannot use devel, and therefore one uninstall the other.
Click to expand...
There is a Makefile option called CONFLICTS_INSTALL for these situations. I am not sure but the right procedure might be creating 2 port directories, one is for devel package and stable package without any pkg namesuffix. I guess poudriere and poudriere-devel might be a good example. Good luck!
 
  • Thanks
Reactions: mrd
elephant said:
I think the problem is there are two use cases. An individual like you or I wants to build a port with the least effort necessary. In contrast, the FreeBSD package system MUST build everything. The package system isn't penalized like us for situations like the one you describe.
Click to expand...
You have to learn the entire ports framework which is too much asked for a 1000 lines single-file program. Using FreeBSD for 20 years but I never made an official port because it's a massive maze that takes too much time with few results. I would contribute to a program that covers it in tree-style using checkboxes. Processing a list of supposed standardized things that have to happen to create a working ports-entry that installs and builds using make shoudn't be that complex. Quite sure it can't be done because the exact requirments aren't clear and also can change with major versions. An idea is to create a concept portstree with 1 port and document the function of all involved files that are not part of the program itself.
 
  • Thanks
Reactions: mrd
MG said:
You have to learn the entire ports framework which is too much asked for a 1000 lines single-file program. Using FreeBSD for 20 years but I never made an official port because it's a massive maze that takes too much time with few results. I would contribute to a program that covers it in tree-style using checkboxes. Processing a list of supposed standardized things that have to happen to create a working ports-entry that installs and builds using make shoudn't be that complex. Quite sure it can't be done because the exact requirments aren't clear and also can change with major versions. An idea is to create a concept portstree with 1 port and document the function of all involved files that are not part of the program itself.
Click to expand...
The best starting point would be reading different but similar ports as you want to port and see what they do. And read Porter's Handbook with Mk/bsd.port.mk for anything you cannot understand what's done.
 
  • Thanks
Reactions: mrd
T-Aoki said:
The best starting point would be reading different but similar ports as you want to port and see what they do. And read Porter's Handbook with Mk/bsd.port.mk for anything you cannot understand what's done.
Click to expand...
That's approach from the wrong side, in my opinion. I made hello_world.c. Where can I find the things that are needed to make it a port that can be built and installed with the "make install" command? This is a checklist...
 
  • Thanks
Reactions: mrd
MG said:
That's approach from the wrong side, in my opinion. I made hello_world.c. Where can I find the things that are needed to make it a port that can be built and installed with the "make install" command?
Click to expand...
You don't need to do so if you don't want to share your efforts with others.

And note that some of dependencies could "fit" for FreeBSD using ports framework, making things differ from the upstream assumes.
This often happenes when multiple versions of something are sanely coexisiting while upstreams assume all versions to be installed in same directories with same filenames.
 
  • Thanks
Reactions: mrd
I decided to pursue the strategy to not let the two versions coexist at the same time. Jails can help to have stable and dev coexisting on the same OS.

It is better to work daily on the "devel" version and have the "stable" on a jail in my opinion...
 
T-Aoki said:
You don't need to do so if you don't want to share your efforts with others.

And note that some of dependencies could "fit" for FreeBSD using ports framework, making things differ from the upstream assumes.
This often happenes when multiple versions of something are sanely coexisiting while upstreams assume all versions to be installed in same directories with same filenames.
Click to expand...
devel/hello_world has no dependencies and only 1 version. It's on my github.
First thing needed: a working Makefile that fetches the source file and registers the package hello_world. The result is /usr/local/bin/hello_world existing and pkg info showing it as installed package.
If the next version gets more complex, we can look at new requirements to keep it working as a port, but that's irrelevant for now...
 
MG said:
That's approach from the wrong side, in my opinion. I made hello_world.c. Where can I find the things that are needed to make it a port that can be built and installed with the "make install" command? This is a checklist...
Click to expand...
If you don't have a Makefile, you'll need to use do-build: and do-install: and USE_GITHUB.
Examples: x11/xrsi, x11/xtrlock, x11/mons
If no version is available, use DISTVERSION=gYYMMDD and GH_TAGNAME=.
 
Hello guys.

The ports now follow the recommended way to dealing with GO modules.
And it has passed the dos and don't dos; the portlink check looks correct.

So far I have all the files in a VM, now I wonder if I had better to bring the ports "live" on my system or into poudriere.
 
This is confusing me:

Code: 
ZPOOL=zroot
BASEFS=/usr/local/poudriere
DISTFILES_CACHE=/usr/ports/distfiles
RESOLV_CONF=/etc/resolv.conf

Why does Poudriere use /usr/ports/distfiles as cache?
It is not the goal of Poudriere keeping everything isolated from the host?
 
mrd said:
This is confusing me:

Code: 
ZPOOL=zroot
BASEFS=/usr/local/poudriere
DISTFILES_CACHE=/usr/ports/distfiles
RESOLV_CONF=/etc/resolv.conf

Why does Poudriere use /usr/ports/distfiles as cache?
It is not the goal of Poudriere keeping everything isolated from the host?
Click to expand...
No.
/usr/ports/distfiles/ is the default directory for ports framework to store fetched distfiles of EVERY ports. Some create subdirectories there.

And poudriere allows setting different place to fetch distfiles, isolated from default place. This would be because fetching the same distfiles multiple time force upstream infrastructure to be overbloated.
Not sharing /usr/ports/distfiles within bare-metal and poudriere is simply silly and unrespectful impolite thing to upstream. I don't think DISTFILE_CACHE variable is even worth existing.
 
Poudriere is making everything more complex than it should it be, which is already complicated; I think I'll move the ports from the VM to the host, since Hopefully the ports are ready for submission.
 
I am on a tethering connection, I need to speed up my connection by using socks5 otherwise it would take forever; however it looks it is not feasible:


Do you guys have any recommendation?
 
I was able to build a port with Poudriere... 🎊 🍾 🙏

mrd

Solved Post in thread 'Poudriere go:modules and GHT_TUPLE issues with custom build script'

I was able to build it with Poudriere:

Code: 
[00:06:31] [01] [00:06:24] Finished print/publisher | publisher-5.4.0: Success
[00:06:32] Stopping 1 builders
15amd64-latest-job-01: removed
15amd64-latest-job-01-n: removed
[00:06:33] Creating pkg repository
Creating repository in /tmp/packages: 100%
Packing files for repository: 100%
[00:06:47] Committing packages to repository: /usr/local/poudriere/data/packages/15amd64-latest/.real_1772289575 via .latest symlink
[00:06:47] Removing old packages
[00:06:47] Built ports: print/publisher
[15amd64-latest] [2026-02-28_09h32m48s] [committing] Queued: 1...
 
Hi guys, I'd like to submit my ports.

The ports are now inside Poudriere, can I submit them from Poudriere, or must I move everything into the OS ports directory?
 
Hello mrd!

It need not be in /usr/ports. For example, if you did a 'git clone' of freebsd-ports to a different directory, you could use that.

To protect my own sanity when doing this kind of work, I create a separate branch for the new code. I can do a diff between main and working branches to confirm changes. Since your work spans multiple ports, you may need to separate them into different branches. If the ports are tightly coupled it would make sense to me to include them all in the same "hail mary" patch but that also makes the size of the review larger. You could start with the port with the least dependencies and submit that first. Some of the feeback would likely apply to the other ports. I leave that choice up to you.

Submit a git-diff style patch created from the port's own working directory. Do a make clean first so that only the minimum number of files remain. Also, the patch should be flattened so that, when applied, it appears as a single commit. Attach the patch to a new issue in bugzilla.

A more elaborate way is to use phabricator. Given the size of your patch (multiple ports), this may be better.


You can create a review that looks something like this (not the best as it's an X11 font) example:

⚙ D41709 [new port] x11-fonts/fixel: Geometric and humanist grotesque

reviews.freebsd.org reviews.freebsd.org

Odds are you will get some feedback in the review. The wiki page above describes a tool called arcanist that helps streamline the process of updating your patch.
 
You must log in or register to reply here.
Back
Top