Synth: Introducing new custom package repository builder for FreeBSD and DragonFly

Hi all,

Is there are recommended way to use synth to upgrade the version of php in use? My site is currently running php v7.0 and I'd need to move to v7.1 or higher.

In the past, using ports-mgmt/portmaster etc I kept running into problems doing this, ie, it took several attempts to upgrade versions of PHP and Perl. It is one of those tasks that I as a very part-time sysadmin only undertake from time to time; I forget how to do it properly and end up breaking my Joomla, Roundcube, and Nextcloud setup.

Yesterday I tried simply installing lang/php71 using synth, hoping it would update the dependencies according, but yet again I ran into problems, and had to revert to php70 to get everything working again.

Thanks for pointing me in the right direction.
 
I've added that line to /etc/make.conf, thanks.

Reinstalling nextcloud, I'm prompted for the flavor, so I choose nextcloud@php72, obviously.

But when I try to reinstall joomla3, there are no flavors, and synth deletes all the php72 dependencies and reinstalls the php70. :( :( :(

Once again, I have reverted to php70 to run Joomla.
 
When using synth, you need to add DEFAULT_VERSIONS+=php=72 in your /usr/local/etc/synth/LiveSystem-make.conf file.

That should fix your issue.
 
freebsdinator said:
I'm also trying to understand if synth is dynamic enough to build a package for a client that requests a port to be installed or if I have to go to synth first.
Click to expand...
My, but that would be too damn "dynamic", wouldn't you think so? I'm afraid your help will be needed for Synth to understand which particular port the client requests.

Seriously, though, the degree of the supposed "dynamism" can be imagined. For example, does it make any sense building a separate package for an unknown machine without building the dependencies? So, the dependencies WILL be needed. But then, up to what depth? What packages/versions are already installed on the target client machine?

So, you create a corresponding PROFILE and keep the needed packages in sync with the ports tree -- then you can add another package to that repository. Then you make that repository available to your client machine and then install whatever packages that machine would need. Your client's pkg command will know which dependencies from the repo it needs and which are already installed. I hope that covers it more or less.
 
So, was a bit of work, but set up a build server so I can custom build ports --> packages for my personal workstation. Initially used ports-mgmt/poudriere but I find ports-mgmt/synth to be faster at builds and easier to manage. So far so good, works like a charm! Got my repository set up and my workstation happily uses it. Only bad part was the initial set up of figuring out which packages I had used, configuring the ones I needed to, then building a file with the list so ports-mgmt/synth could build them and create the repo. Now it's just maintenance so no worries.
 
When you run synth status, does the display order show what the dependencies are?

For example :
Code: 
These are the ports that would be built ([N]ew, [R]ebuild, [U]pgrade):
  N => security/openssl111
  R => lang/python27
  ...
  ...
  N => security/openssl
  R => security/py-fail2ban@py36
  ...
  ...

Does the above mean that security/py-fail2ban depends on security/openssl port?

I'm curious why fail2ban won't compile using security/openssl111 instead.
 
After updating my VPS to v12.0-RELEASE today using freebsd-update, I am trying to update the ports, but synth is choking on something:
$ sudo synth upgrade-system
Builder mounts detected; attempting to remove them automatically ...
Dismounting successful!
Regenerating flavor index: this may take a while ...

raised REPLICANT.SCENARIO_UNEXPECTED : /usr/sbin/mtree -p /usr/obj/synth-live/SL09/var -f /etc/mtree/BSD.var.dist -deqU => failed (exit code not 0)
Click to expand...
Any ideas about what is going wrong here?
 
Is ports-mgmt/synth still receiving maintenance-love?

A) It's repo conf file in /usr/local/etc/pkg/synth is being ignored by FreeBSD 13-RELEASE. You'd need to write it's content manually into conf file in /etc/pkg for synth repo to be visible for OS.

B) Used to be that only first package builds (upgrade-system or some package install) were all-inclusive and after updating ports and issuing it again - only ports installed and with any changes were rebuilt. Now ports-mgmt/synth seems to build same packages over and over completely uncaring whether packages of same version&options already exist in repo or not.
 
aht0 said:
Is ports-mgmt/synth still receiving maintenance-love?

A) It's repo conf file in /usr/local/etc/pkg/synth is being ignored by FreeBSD 13-RELEASE. You'd need to write it's content manually into conf file in /etc/pkg for synth repo to be visible for OS.

B) Used to be that only first package builds (upgrade-system or some package install) were all-inclusive and after updating ports and issuing it again - only ports installed and with any changes were rebuilt. Now ports-mgmt/synth seems to build same packages over and over completely uncaring whether packages of same version&options already exist in repo or not.
Click to expand...
A)I guess it IS ignored. The correct path is /usr/local/etc/pkg/repos/. There you place your Synth.conf and FreeBSD.conf.

B)Actually, it rebuilds changed ports + ANY ports that could possibly be affected. There is some policy about it which seems to be common to all package site build tools. It has been so from the start (many complained about it).
Though I had recently this problem, that it rebuilt ALL my packages. But since then it's working as expected.

EDIT: And yes, its maintainer seems to be still working on it, last comment was 21 day ago. Though he doesn't quickly answer to problems not related to Synth...
 
Yeah, I remembered path name to conf file wrong, I was typing that post from phone at the time.
I installed synth from the binary package and for some reason "13" didn't use it's automatically created configuration file until I manually intervened. Then ran into issue where synth tried to rebuild packages over and over, despite them already having been built before without any changes in port options.

Ended up deleting all packages from system, deinstalling synth and installing everything from zero using only binary packages.
 
When upgrading packages, Synth does not remove the old symbolic links. I see someone has already reported this issue on Github in January, and it was never replied too.

Until we get a fix, you use the following to remove all orphaned symlinks in the the /var/synth/live_packages/All folder.

find -L /var/synth/live_packages/All -type l -print0 | xargs -0 rm
 
You must log in or register to reply here.
Back
Top