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

mrd if your intent is to become a port maintainer, this will be an excellent experience. If not, you can do the simpler path of creating an issue in bugzilla and attaching the patch there. Regardless, everyone appreciates your efforts.
 
elephant said:
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.
Click to expand...
If you don't want to create local branch and anything new is added into ports tree, procedure below at the top of your ports tree (basically /usr/ports by default) allows to generate wanted style of diff.
Code: 
git stash --include-untracked
git stash show -p --include-untracked > /filename/to/save/patch
git stash pop

This would contain noises if your ports tree has changes anything others than you want. So cleanups of the generated patch is needed in this case.

The last command is to restore your changes.

Now you have proper patch to upload to Bugzilla (bugs.freebsd.org).

For patches to upload to Phabricator (review.freebsd.org), additional -U999999 option is needed for the 2nd command.

This is how I'm generating patches.
 
elephant said:
mrd if your intent is to become a port maintainer, this will be an excellent experience. If not, you can do the simpler path of creating an issue in bugzilla and attaching the patch there. Regardless, everyone appreciates your efforts.
Click to expand...
Maintainers are not forced to create branches.
But committers is required to do so as they need to push the changes to master repo. Note that no one who are NOT committers cannot push changes to master repo. And recently the assignee of PRs on Bugzilla is mandated to be a committer (before the change in policy, non-committer maintainers can be a assignee).
 
Everything became too much abstract that is extremely hard for me to grasp now.

Can I symlink the two Poudriere directories, where I created and tested the ports, into my system port tree to create the diff file?

Oh my gosh... There is also a committer books... 😱😭
 
The idea behind a separate branch was to make creating a patch easier. If you've ever worked on two or more reviews at once, you'll understand why. If mrd can create a patch, that is sufficient. mrd you are in a simpler place in that the port(s) are new. If you can create a tarball of new port directories only, that might be sufficient for attaching to a bugzilla ticket.
 
elephant said:
The idea behind a separate branch was to make creating a patch easier. If you've ever worked on two or more reviews at once, you'll understand why. If mrd can create a patch, that is sufficient. mrd you are in a simpler place in that the port(s) are new. If you can create a tarball of new port directories only, that might be sufficient for attaching to a bugzilla ticket.
Click to expand...

I guess I can.
I am sorry that I am clearly struggling to understand these concepts... 😩
 
Code: 
$ cp -ia publisher /usr/ports/print/
$ cd /usr/ports/print/publisher
$ git add .
$ git diff --staged >/tmp/publisher.diff
$ git rm -r --cached .
 
The port was pushed back... several issues, I need to rework it.


There are several things I need to understand how to address differently.
Among the various comments these are the ones that I understood the least:

  • libraries usually go into ${PREFIX}/lib, not share, though there can be exceptions if the libraries are opened by dlopen.
  • libraries need to have a soname set and the usual symlinks installed. Is this the case?
Click to expand...

For the first bullet, what should I do if the software expect to find the libraries in /usr/local/share/... instead of ${PREFIX}/lib, create a symbolic link?

I honestly did not understand the second bullet point.

Thanks.
 
For the second point, look at /usr/local/lib. You'll see multiple examples of the same library appear under three or four names.

$ ls -lat /usr/local/lib/libxcb-util*
-rw-r--r-- 1 root wheel 22382 Dec 17 19:24 /usr/local/lib/libxcb-util.a
lrwxr-xr-x 1 root wheel 20 Dec 17 19:24 /usr/local/lib/libxcb-util.so -> libxcb-util.so.1.0.0
lrwxr-xr-x 1 root wheel 20 Dec 17 19:24 /usr/local/lib/libxcb-util.so.1 -> libxcb-util.so.1.0.0
-rwxr-xr-x 1 root wheel 16224 Dec 17 19:24 /usr/local/lib/libxcb-util.so.1.0.0

libxcb-util.so.1.0.0 is the actual shared object library. The other two shortened file names point to it.

I think the idea is dependent code can choose to bind against the shortened form so that minor revisions to the library don't require a rebuild of the dependent code.
 
mrd said:
The port was pushed back... several issues, I need to rework it.


There are several things I need to understand how to address differently.
Among the various comments these are the ones that I understood the least:



For the first bullet, what should I do if the software expect to find the libraries in /usr/local/share/... instead of ${PREFIX}/lib, create a symbolic link?

I honestly did not understand the second bullet point.

Thanks.
Click to expand...

Hello,

I have tried to make a port and have just committed it. This is how I managed FreeBSD paths and shared libraries.

Since I didn’t write the original code I first made the mistake of compiling it in my /home/user directory.

Once it compiled I looked at the output and where the executable and the libraries ended up.

As expected the executable was not in /home/user/portsource/usr/local/bin and the libraries were not in /home/user/portsource/usr/local/lib. Here I made my second mistake. I altered the source code to produce executable in /home/user/portsource/usr/local/bin and same to make the libraries end up where I wanted them to be. Total waste of time.

What I should have done was to create a directory for my port in the ports tree and use the power of the Makefile to compile the source. Once the Makefile built the executable and the libraries all I had to do was to move them to the stage directory. I did this in the Makefile like below and I also did the symlinking for the .so libraries there as well.

Earlier in the Makefile I have the line that links the libraries making them accessible to the executable.

The linking looks like this:

Code: 
USE_LDCONFIG=    ${PREFIX}/lib/entropypianotuner ${PREFIX}/lib/entropypianotuner/algorithms

The moving of the built executable and libraries from work to stage looks like this:

Code: 
do-install:
    ${INSTALL_PROGRAM} ${WRKSRC}/bin/entropypianotuner ${STAGEDIR}${PREFIX}/bin/
    ${MKDIR} ${STAGEDIR}${PREFIX}/lib/entropypianotuner
    ${INSTALL_LIB} ${WRKSRC}/bin/libcore.so.1.0.0 ${STAGEDIR}${PREFIX}/lib/entropypianotuner/

    ${RLN} ${STAGEDIR}${PREFIX}/lib/entropypianotuner/libcore.so.1.0.0  ${STAGEDIR}${PREFIX}/lib/entropypianotuner/libcore.so
    ${RLN} ${STAGEDIR}${PREFIX}/lib/entropypianotuner/libcore.so.1.0.0  ${STAGEDIR}${PREFIX}/lib/entropypianotuner/libcore.so.1
    ${RLN} ${STAGEDIR}${PREFIX}/lib/entropypianotuner/libcore.so.1.0.0  ${STAGEDIR}${PREFIX}/lib/entropypianotuner/libcore.so.1.0

    ${MKDIR} ${STAGEDIR}${PREFIX}/lib/entropypianotuner/algorithms
    ${INSTALL_LIB} ${WRKSRC}/bin/algorithms/libentropyminimizer.so ${STAGEDIR}${PREFIX}/lib/entropypianotuner/algorithms/
    ${INSTALL_LIB} ${WRKSRC}/bin/algorithms/libpitchraise.so ${STAGEDIR}${PREFIX}/lib/entropypianotuner/algorithms/
    ${INSTALL_LIB} ${WRKSRC}/bin/algorithms/libresettorecording.so ${STAGEDIR}${PREFIX}/lib/entropypianotuner/algorithms/

You can see the entire Makefile in this thread #18

Hopefully this will help you forward.

/grandpa
 
grandpa

Thank you very much, this will be of great help.
I am focusing on other projects but I look forward to get back to this one, I really need to make it working! 💪
 
You must log in or register to reply here.
Back
Top