Solved Port Maintenance Guide help (preferably exhaustive)

Can't find any guides on port maintenance step by step. Looking for someone to help clean up this guide I created for myself. My main question is where in these steps do I upgrade the port to the newer version if there is one, and how do I do this? I want to get into maintaining ports, I think it will be a good learning opportunity for me. Please add/cleanup to any of this and include different ways of maintaining.

1.svn co https://svn.freebsd.org/ports/head/category/port
2.modify makefile and pkg-plist
3.test those changes with make config, make patch, and make configure
4.run portlint & poudriere etstport
5.make a patch with diff
6.diff -ruN /usr/ports/category/port . >/tmp/port.patch
7.svn diff category/port > portdiffs/category/port.diff
8.create a PR and attach diff
 
My main question is where in these steps do I upgrade the port to the newer version if there is one, and how do I do this?
I just checkout a new copy. Like you do in step one. Then work from that new copy. If you have an existing copy you can update it with svn update. But if you have modifications already in place those might conflict and you may get merge conflicts. So I always work from a "clean" copy. Steps 5, 6 and 7 appear to be the same thing. For the moment you just need step 7 to get a proper diff to submit. Note that this will likely change somewhere around March next year when the ports tree is migrated to git.

 
The definitive source for maintaining ports is of course the Porter's Handbook, but it doesn't tell you anything about a workflow regarding SVN (and soon GIT).

For now, I prefer to have a local ports tree as a subversion working copy for ports-mgmt/poudriere. So, don't check out a single port (won't work with GIT any more anyways) but the whole tree.

You can do your changes and test a few basic things by just setting the environment variables PORTSDIR and DISTDIR matching the paths used by poudriere. When you're satisfied, test with poudriere testport (and you can configure poudriere to also run portlint as part of that).

For creating a diff to submit, svn diff category/port from the root of your ports tree will normally do fine.

For updating, just use svn up on your whole tree.

I'm personally looking forward to GIT as I can finally use local branches for my local and to-be-tested changes.
 
I just checkout a new copy. Like you do in step one. Then work from that new copy.
doesn't that mean the port is already upgraded? Like, doesn't it defeat the point to be upgrading a port if the port in the tree is already upgraded?
 
doesn't that mean the port is already upgraded?
Then what are you trying to maintain here? You'll want to get the latest revision of the port as it currently is in the ports tree. You work from that.
Like, doesn't it defeat the point to be upgrading a port if the port in the tree is already upgraded?
You asked about how to maintain a port. That means you are providing that update. But you still want to work off of the current version that's in the ports tree to keep your patches in sync or else the svn diff you created in step 7 won't be able to be imported by ports management.
 
I just checkout a new copy. Like you do in step one. Then work from that new copy. If you have an existing copy you can update it with svn update. But if you have modifications already in place those might conflict and you may get merge conflicts. So I always work from a "clean" copy. Steps 5, 6 and 7 appear to be the same thing. For the moment you just need step 7 to get a proper diff to submit. Note that this will likely change somewhere around March next year when the ports tree is migrated to git.

Thank you guys for your help again, I know I've asked about port maintenance in the past, and that's where I got this guide anyway, but just wanted to touch it up and understand it better. Also, thanks for constantly monitoring this forum. I'm not the best with computers but the documentation and support makes it so that really doesn't matter!

P.S.
I'm having trouble with poudriere testport after about 1-5 built dependencies. This has been happening on my last oldish amd64 CPU and my brand new i386 CPU. What are some good troubleshooting steps? I've tried
"change your configuration and see what happens", including increasing and decreasing number of build jobs.
 
I'm having trouble with poudriere testport after about 1-5 built dependencies. This has been happening on my last oldish amd64 CPU and my brand new i386 CPU. What are some good troubleshooting steps? I've tried
"change your configuration and see what happens", including increasing and decreasing number of build jobs.
What kind of problems are you are having? Build failures due to conflicting options? Running out of memory/swap during the build? Conflicting build options can be troublesome, I play around with options a lot and regularly run into those. Just take a look at the build logs for the failing port, see why it fails and change the options accordingly. Running out of memory and/or swap is also quite possible, certainly with bigger builds like Firefox, Chromium or the various Webkit implementations. These suck up a lot of resources.
 
I just checkout a new copy. Like you do in step one. Then work from that new copy. If you have an existing copy you can update it with svn update. But if you have modifications already in place those might conflict and you may get merge conflicts. So I always work from a "clean" copy. Steps 5, 6 and 7 appear to be the same thing. For the moment you just need step 7 to get a proper diff to submit. Note that this will likely change somewhere around March next year when the ports tree is migrated to git.


What kind of problems are you are having? Build failures due to conflicting options? Running out of memory/swap during the build? Conflicting build options can be troublesome, I play around with options a lot and regularly run into those. Just take a look at the build logs for the failing port, see why it fails and change the options accordingly. Running out of memory and/or swap is also quite possible, certainly with bigger builds like Firefox, Chromium or the various Webkit implementations. These suck up a lot of resources.
It stalls and stops making progress for the build. It doesn't fail or end though. I tried the example in the poidriere section of the porters handbook and found a couple more examples without options too that have done no better. I will try an application with less dependencies and see if the problem persists. I've never messed with the swap space though. This is like fake RAM isn't it. I'm not sure what part that play in the build process. Could you elaborate? I will be back with the log info.
 
It stalls and stops making progress for the build. It doesn't fail or end though.
Does poudriere still react on CTRL+t? Then it's still running. You can check progress of individual packages being built e.g. with tail(1) on their log files. Some large ports will take a long time to build, just let it complete…

For repeated builds, it makes a lot of sense to install devel/ccache and configure poudriere to use it.
 
I can highly recommend using the web interface for poudriere, it makes it easier to see what it's doing, look at logs, etc. There are some example configuration files for Apache and nginx in /usr/local/share/examples/poudriere/. I've added a few things to my nginx configuration so I can use the same webserver to also serve the created package repositories.
 
Does poudriere still react on CTRL+t? Then it's still running. You can check progress of individual packages being built e.g. with tail(1) on their log files. Some large ports will take a long time to build, just let it complete…

For repeated builds, it makes a lot of sense to install devel/ccache and configure poudriere to use it.

I can highly recommend using the web interface for poudriere, it makes it easier to see what it's doing, look at logs, etc. There are some example configuration files for Apache and nginx in /usr/local/share/examples/poudriere/. I've added a few things to my nginx configuration so I can use the same webserver to also serve the created package repositorieI've never used a webserver. do I just use the example configuration as the configuration for nginx and go to the specified URL in the configuration file?

I can highly recommend using the web interface for poudriere, it makes it easier to see what it's doing, look at logs, etc. There are some example configuration files for Apache and nginx in /usr/local/share/examples/poudriere/. I've added a few things to my nginx configuration so I can use the same webserver to also serve the created package repositories.
I've never used a webserver before. Do I just use the configuration file in the poudriere examples as the Nginx configuration file and enter the specified URL in the web browser?
 
Does poudriere still react on CTRL+t? Then it's still running. You can check progress of individual packages being built e.g. with tail(1) on their log files. Some large ports will take a long time to build, just let it complete…

For repeated builds, it makes a lot of sense to install devel/ccache and configure poudriere to use it.
Do I find the path to ccache with locate or which or whereis or find and enter the path into the poudriere configuration file to use ccache?
 
Do I find the path to ccache with locate or which or whereis or find and enter the path into the poudriere configuration file to use ccache?
If /usr/obj is a inconvenient place, you can set CCACHE_DIR to your choosing.
 
I've never used a webserver before.
Time to learn. If I remember correctly for the RHCSA exam I had to configure Apache and a virtualhost, I did that from the top of my head as I've done this a million times already. Knowing how different webservers are configured is in itself useful. It'll give you more insights into how the world wide web actually works.

Do I just use the configuration file in the poudriere examples as the Nginx configuration file and enter the specified URL in the web browser?
The example is a http and server section of the nginx config. You need to apply those in the right places in your nginx.conf.
 
Back
Top