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

[basbebe]

The error is about the host environment, not the jail environment.
In other words, add "env TERM=xterm" to the command.

But given the cron command above, the entire thing looks wrong.
Create a dedicated "cron" profile, once that doesn't have ncurses enabled, and use "env SYNTHPROFILE=newprofile". See the man page for environment variables that are used.

If you're still seeing that TERM is required even with a profile that doesn't use ncurses, that may be a recently introduced bug. But lots of people use synth with cron and nobody else complained of a recent bug involving TERM.

I already have ncurses disabled for the default profile (LiveSystem).
I thought that that LiveSystem-environment file (which of course is in the host environment) would do exactly the same like env TERM=xterm" in the command…?

 

[marino]

LiveSystem-environment is for the JAIL. The term is missing from the HOST environment.

the immediate fix is prefix all synth commands with "env TERM=dumb".
It doesn't see to care about ncurses any more, it wants TERM defined always.

edit:
May sure you remove TERM from the environment profile.
The environment file is only used by < 1% of synth users. You shouldn't need it all unless you've got a proxy or something.

 

[nickednamed]

Hi all,

First, thank you jrmarino. Synth is working well for me. I have a question for which I'm sure there is an answer, but I can't get my head round it.

I'm tracking the quarterly pkg repo, and the quarterly ports repo, and I have the "Fetch prebuilt packages" set to "true" because I don't want to be building too often (running FreeBSD on a laptop), but I seem to be rebuilding things over and over.

For example, over the last few weeks the security/nss, and security/ca_root_nss ports have been updated multiple times, and each time synth status tells me I need to Update these two ports, and Rebuild around 94 others (sometimes more, sometimes less), including a few big programs like www/firefox, editors/libreoffice, print/texlive-texmf and others (some of which are build only dependencies).

From what I understand (I'm really nothing more than a casual user) when a pkg is upgraded all dependant ports/pkgs must be rebuilt. Fair enough.

But I seem to remember ports-mgmt/pkg simply reinstalling certain packages whose dependencies had been updated. Is this possible with Synth / pkg?

Is there some way to minimise the rebuilding of already installed, and not updated programs?


Also, as a sperate issue, after running synth install security/nss security/ca_root_nss , then pkg upgrade -r Synth (just to check) it shows that one of the two still needs updating:

Installed packages to be UPGRADED:
   ca_root_nss: 3.30.1 -> 3.30.2 [Synth]

Is this the expected behaviour?

EDIT: OK, so I looked into it more, and I guess this is the expected behaviour. pkg will not reinstall rebuilt packages unless options or versions have changed. Now using pkg upgrafe -rf Synth.

 

[hrenznaet]

I've tried synth as everyone was advertising synth (or poudrierre) over portmaster.
I don't know why people advise it, because in my opinion portmaster wins over synth.

Synth is not even able to invoke 'make config' when needed. So synth users have to use portmaster for that anyways. If I have to have and have to use portmaster anyways - why would I need synth?
It ignores ports that require license confirmation and skips ports dependent on those. Why not just ask the user's prompt at the start of the building queue?
It fails dependency checks. It doesn't explain anything on that, it just says it failed dependency checks.
Synth wastes time and resources on useless routines: if one runs 'synth upgrade-system' twice in a row and both times some port(s) fail - the 2nd run's queue will consist only of failing ports.
If a queue consists only of ports that are ignored/skipped/failed - there is no need to recursively rescan whatever synth scans and rebuild whatever db it rebuilds. But synth still does that.

One might think that the above issues are just bugs and missing features (which software has no bug?), but looks like it's author is against those features, so it becomes a political issue.

Sometimes synth wins over portmaster when port maintainer screwed up something and the port can't be built using portmaster but builds with synth. But there are also the cases when the opposite takes place.

That being said - I still use synth, but I don't really know why.

 

[marino]

Everything you've written is a product of ignorance about the topic.

If I have to have and have to use portmaster anyways - why would I need synth?

No. If you have to "make config" you don't need portmaster, you just run "make -C <portpath> config". So that's blatently false.

It ignores ports that require license confirmation

That's the port system doing that. I means you failed to pre-accept the license in your profile make.conf. Synth is doing as instructed. If you want it to do something different, you have to provide instruction.

Why not just ask the user's prompt at the start of the building queue?

Why not preapprove the license? It's a one time thing. (or disable licence checks, see next post) The premise is NEVER interact. Once you understand that synth intentionally does not stop in the middle of a run (a glaring issue of both portmaster and portupgrade), design decisions may make more sense.

It fails dependency checks. It doesn't explain anything on that, it just says it failed dependency checks.

There are this things called "logs". Yes, it's logged. Yes this information is on the man page. Yes, there's a way to show this information on the screen in real time (this is also explained in the man page).

f one runs 'synth upgrade-system' twice in a row and both times some port(s) fail - the 2nd run's queue will consist only of failing ports.

What does that even mean? Most people want the queue to consist of the missing ports. Are you saying it should rebuild EVERYTHING on the second try? If you want that (again, most people would not), then use a build command that will force the rebuild.

If a queue consists only of ports that are ignored/skipped/failed - there is no need to recursively rescan whatever synth scans and rebuild whatever db it rebuilds. But synth still does that.

There's no db. Nothing is cached. Any change to the ports system (e.g. option change, or ports tree update) would invalidate such a db. As synth doesn't know if such a change occurred, it assumed is did.

One might think that the above issues are just bugs and missing features...

Actually, one would think this person hasn't read the manual yet speaks on topics they are clearly over their head with.
With regard to "missing features", it's not missing if they were thoughtfully and intentionally excluded. You may disagree with the decision, just as I disagree with your terminology.


Congrats, you managed to troll me into a response.

All of this, and the previous post, as been hashed out many timed in this very thread.

 

[marino]

by the way, anybody that doesn't want licensing to ever block the build, put this in /usr/local/etc/synth/<profile>-make.conf:

DISABLE_LICENSES=yes

Similarly with packages, to prevent package restrictions, put this:

FORCE_PACKAGE=yes

Again, these are both handled by the ports tree. The behavior is not coming from Synth.

 

[talsamon]

I don't really want join the discussion.
But I don*t understand why
portmaster is able to call dialog4ports and
synth not. And you refuse to code a few lines that synth are able to do this (or something similar with dialog or a "macro" with make -C /usr/ports/$1 config or whatever)..
If ten ports changes the options, synth interrupts ten times....

 

[fernandel]

I don't really want join the discussion.
But I don*t understand why
portmaster is able to call dialog4ports and
synth not. And you refuse to code a few lines that synth are able to do this (or something similar with dialog or a "macro" with make -C /usr/ports/$1 config or whatever)..
If ten ports changes the options, synth interrupts ten times....

When I did start with Synth from the first vesion I also thought that Synth interrupts you whatever times but not. If you are looking a little more above what messages are there you will saw all ten changes for example.

 

[talsamon]

Ok. I don't follow all changes with synth. Maybe, so I
misinterpreted some of the posts. If it is so, then sorry for it.

 

[hrenznaet]

Everything you've written is a product of ignorance about the topic.

No. If you have to "make config" you don't need portmaster, you just run "make -C <portpath> config". So that's blatently false.

That's idiotic. Why would I make config a single port? I have a lot of ports, I need to work with them as a bunch, not with each one separately.

That's the port system doing that. I means you failed to pre-accept the license in your profile make.conf. Synth is doing as instructed. If you want it to do something different, you have to provide instruction.

I don't need your explanations. Your util doesn't ask me whether I'd like to accept the license, which in my opinion a port managing tool should do.
I don't care if you think otherwise, I'm expressing my opinion about why your util sucks.
Feel free to ignore it, as you already got used to.

Why not preapprove the license? It's a one time thing. (or disable licence checks, see next post) The premise is NEVER interact. Once you understand that synth intentionally does not stop in the middle of a run (a glaring issue of both portmaster and portupgrade), design decisions may make more sense.

Because I might not want to preapprove licenses.
In my opinion a port updating tool should be able to show a license agreement prompt.
I also don't like the premise of never interact, I'd rather see the tool to run all the required interaction before it starts to build so that I could just forget about it later.
Some interaction is required.
If some people prefer to have absolutely no interaction - I think it should be done via a command key.
Vice versa (automatic by default + use a key for interactive mode) would also be acceptable (though not optimal, IMO).

There are this things called "logs". Yes, it's logged. Yes this information is on the man page. Yes, there's a way to show this information on the screen in real time (this is also explained in the man page).

And that was the quote from /var/log/synth/04_skipped_list.log.
I probably should have looked at the exact logs of those skipped ports instead of 04_skipped_list.log, but I'd like to have a short summary on each skipped port in a single file.

What does that even mean? Most people want the queue to consist of the missing ports. Are you saying it should rebuild EVERYTHING on the second try? If you want that (again, most people would not), then use a build command that will force the rebuild.
There's no db. Nothing is cached. Any change to the ports system (e.g. option change, or ports tree update) would invalidate such a db. As synth doesn't know if such a change occurred, it assumed is did.

No, what I meant is that if a run's result is that 0 ports got built - there's no need to do some steps, like recursively scanning ports tree. Because nothing got modified.

Actually, one would think this person hasn't read the manual yet speaks on topics they are clearly over their head with.
With regard to "missing features", it's not missing if they were thoughtfully and intentionally excluded. You may disagree with the decision, just as I disagree with your terminology.

I know some of the points were discussed before, I also do disagree with some of your decisions, I just expressed my opinion as someone else might be too lazy to try your util to get a gist of it, but might be curious about because quite very many people actively advertised your util as if it's something awesome.
To be fair, I also had a tiny hope that you, as a developer, might see that more and more people nag/complain about the same missing features that you 'thoughtfully and intentionally excluded' and maybe you'd change your mind, but reading your response I see an arrogant non-conformist behind it.
Well, that's understandable, because we don't pay you for what we ask and thus we are in no position to demand anything, yet we still have our right to just nag/whine, sorry.

 

[marino]

That's idiotic. Why would I make config a single port? I have a lot of ports, I need to work with them as a bunch, not with each one separately.

FACT 1: The vast majority of ports don't need configuring. The default options, the ones that the freebsd cluster uses are the ones desired
FACT 2: Synth runs if all the pre-saved options are valid. Thus, once they are saved, they are known to be good. Once that's not true, synth will not start a new run until they are fixed.
FACT 3: You have a list of ports that you want built, either manually created or created from pkg(8) queries

Thus, you *should* know which of the very few ports you are build need non-standard options and setting those individually is not a burden. In the worse case, where you are one of those few people that have the idea you MUST set every ports options, you can either run your list through a shell script or use another tool to the options recursively which you need to do ONCE. Then if options change in the future, you can set it individually when synth notifies the options are obsolete.

Not to mention FACT 4 where synth uses the existing options set by ports/portmaster if you want.

conclusion: You've portrayed this as some necessary missing feature which actual use proves is anything but.

I don't need your explanations. Your util doesn't ask me whether I'd like to accept the license, which in my opinion a port managing tool should do.
I don't care if you think otherwise, I'm expressing my opinion about why your util sucks.

The util already has your input on the license, through the make.conf file.
It was YOUR failure to set the license or DISABLE licenses.
Are you one of these people that blames everyone and everything else for your own fails? Seems like it.

conclusion: Synth has decided that the information it was given through configuration and specialized make.conf and will not pester you with "Are you sure" garbage questions. It will assume that you are sure about the configuration that YOU set.

Because I might not want to preapprove licenses.
In my opinion a port updating tool should be able to show a license agreement prompt.

Like options, this is a one-time set and forget.
It is not outlandlish to expect you to pre-approve the VERY FEW licenses that require explicit approval.
These have got to be in sub 0.5% of the tree level. So it's another mole hole you've made into a mountain.

No, what I meant is that if a run's result is that 0 ports got built - there's no need to do some steps, like recursively scanning ports tree. Because nothing got modified.

I sufficiently explained why there is no cache of previous runs.

I know some of the points were discussed before, I also do disagree with some of your decisions, I just expressed my opinion as someone else might be too lazy to try your util to get a gist of it, but might be curious about because quite very many people actively advertised your util as if it's something awesome.

There's no antidote against laziness.

To be fair, I also had a tiny hope that you, as a developer, might see that more and more people nag/complain about the same missing features that you 'thoughtfully and intentionally excluded' and maybe you'd change your mind, but reading your response I see an arrogant non-conformist behind it.

What, like all 2 of you?
There is one guy that thinks synth should automatically create save option files whenever a port's default options are accepted so that in the future if the options change, synth will alert so that port can be reviewed. That was something to consider because it has a small bit of legitimacy to the use case, but only a single person requested it.

What you're doing is trying to turn synth back into portmaster so my response is, "just keep using portmaster if that's what you want".
Contrary to what you believe, there's isn't a bunch of people saying these features are so important that their unavailability is the sole reason they don't use Synth.
And finally, I don't care if you use it or not. I only care when you spread fud and misinformation (albeit without intention) about a tool that you clearly haven't mastered.

 

[hrenznaet]

FACT 1: The vast majority of ports don't need configuring. The default options, the ones that the freebsd cluster uses are the ones desired

That's not a fact, that's some b/s.
I, as a user, decide which options I'd like the port to have. It's my choice.
Fact is that it's not always necessary to configure ports for minimal functionality.

FACT 2: Synth runs if all the pre-saved options are valid. Thus, once they are saved, they are known to be good. Once that's not true, synth will not start a new run until they are fixed.

Sorry, I do not understand. What's a 'pre-saved' option? Did you mean default options values for a port?
Even default options sometimes lead to port being unable to get built, because ports system is just a bin and maintainers can toss there whatever code they like and it may be that buggy that it doesn't compile. I regularly file issue reports about such ports.

FACT 3: You have a list of ports that you want built, either manually created or created from pkg(8) queries

Thus, you *should* know which of the very few ports you are build need non-standard options and setting those individually is not a burden. In the worse case, where you are one of those few people that have the idea you MUST set every ports options, you can either run your list through a shell script or use another tool to the options recursively which you need to do ONCE. Then if options change in the future, you can set it individually when synth notifies the options are obsolete.

Yeah, looks like I'm one of those people. I have 977 packages and each was built from ports and for many of the ports I have non-default make configs.
I'm also not going to do anything individually for ports with obsolete options, I prefer to work only with sets of ports (read next about portmaster).

Not to mention FACT 4 where synth uses the existing options set by ports/portmaster if you want.

That's the most important thing, that you, unfortunately, don't seem to take into account: we don't live in a stasis, the time flows and the ports in the repository do evolve. And they get new config options and lose the old ones.
So from time to time I have to re-configure the ports that were configured once already. And that's normal.
Unlike synth, portmaster shows make config screen once it figures out that my current config for a port is outdated.
Portmaster is even smart enough as to scan all ports configs prior to starting upgrading them, so currently I run portmaster first to check if there any new configs that require my attention, then I have to answer 'nay' to the prompt that asks to confirm the upgrade to the following ports and run synth.

I would use synth way less frequently (only for the ports that portmaster fails to build) if synth didn't have such an attitude that it has to re-build every port that was built outside of it. I hate that.

conclusion: You've portrayed this as some necessary missing feature which actual use proves is anything but.

The util already has your input on the license, through the make.conf file.
It was YOUR failure to set the license or DISABLE licenses.

Like options, this is a one-time set and forget.
It is not outlandlish to expect you to pre-approve the VERY FEW licenses that require explicit approval.
These have got to be in sub 0.5% of the tree level. So it's another mole hole you've made into a mount.
I sufficiently explained why there is no cache of previous runs.

No, that's some misunderstanding on your side.
make.conf provides a way to override future prompts with a pre-defined decision.
What if 2 ports have the same license and I'd like to accept it for port A and reject for port B?
You could say that it is some idiocy, while it's actually not at all: port B's older version may have not required to accept a license, but newer versions do.
I might want say 'screw you, dear developer, I'll wait for a fork of the old version', but your approach doesn't leave me such freedom.
You kill freedom with your approach.

conclusion: Synth has decided that the information it was given through configuration and specialized make.conf and will not pester you with "Are you sure" garbage questions. It will assume that you are sure about the configuration that YOU set.

Again, I don't want to configure everything proactively, I prefer minimal interaction to take place when needed.
Why do I have to check the options prior to upgrading? Why can't the machine do this work for me and ask for my interaction when it needs the human to make some decision? I want that. I want my life to be simpler rather than more complex in such things.

There's no antidote against laziness.

There is. It's automation.

What, like all 2 of you?
There is one guy that thinks synth should automatically create save option files whenever a port's default options are accepted so that in the feature if the options change, synth will alert so that port can be reviewed. That was something to consider because it has a small bit of legitimacy to the use case, but only a single person requested it.

There are more users of synth than the commenters in this topic. There are places in the internets other than this forum where users discuss synth (irc, for example).
Forums are not very useful for discussion, because no one is going to read those tens of forum topic's pages just to get familiar with what already got discussed.
Proper way for development is to have an issue tracker for each project.
Preferably on a centralized host like github where lots of users already have an account (because otherwise the project will get less attention and feedback as there is the laziness of registering new account vs using an existing one on a well-familiar centralized system).
In an issue tracker with a sane number of non-finished tickets it's quite easy to find whether feature X was discussed already so that more users could voice out.

But I don't know why I even explain these basics to you, as it's quite clear that you have a quite hostile attitude towards users of your util and not interested in all that.

What you're doing is trying to turn synth back into portmaster so my response is, "just keep using portmaster if that's what you want".
Contrary to what you believe, there's isn't a bunch of people saying these features are so important that their unavailability is the sole reason they don't use Synth.
And finally, I don't care if you use it or not. I only care when you spread fud and misinformation (albeit without intention) about a tool that you clearly haven't mastered.

I'm not some crusader, I don't fight for making X be like Y.
I just want max comfort from the use of the tools I interact with.
The comfort in that sense is the balance between ease of use and functionality/configurability.

In my opinion, synth has only 2 strong points over portmaster:
- it can build ports in parallel (which is supposed to fasten the build process);
- afaiu, it builds ports in a 'clean environment' - I don't really value this feature very much, as it makes the the building process longer, while it usually is needed only when some conflicts across ports appear.

portmaster has strong points over synth:
- it knows when to show make config screens and it does show them;
- it builds 1 port faster than synth does (because unlike synth it doesn't build it in a 'clean environment';
- it shows accept license prompts (but does it in a stupid [all make config screens are shown before the global building process starts, but accept license prompts appear only when the building queue reaches the current port] and buggy [-a key makes it hang up in background whenever portmaster reaches a port that has accept license prompt] way in some cases).

I want all of those strong points in 1 utility. I don't care about its name.

 

[marino]

That's not a fact, that's some b/s.
I, as a user, decide which options I'd like the port to have. It's my choice.
Fact is that it's not always necessary to configure ports for minimal functionality.

It's an easily proven fact.
Given access to your machine, I could determine exactly which ports you have customized to be different than default options. I am quite confident that number is low.
Don't say "BS" without providing any statistics. You're talking to somebody very familiar with the 28,000 ports the collection. As a 3-year committer to ports and a member of pkgsrc for 2 years longer than that, you're talking against a lot of experience. What resume are you relying on to back up your facts?

Sorry, I do not understand. What's a 'pre-saved' option? Did you mean default options values for a port?

No. When you have the configure screen on a port and select "ok", it saves your options to a file. At that point it will never bring the screen up again unless the options change.

Even default options sometimes lead to port being unable to get built, because ports system is just a bin and maintainers can toss there whatever code they like and it may be that buggy that it doesn't compile. I regularly file issue reports about such ports.

Exactly. Non-default options are very often untested and don't work. It's actually risky to customize options. This is the norm, not an exception to the rule.

Yeah, looks like I'm one of those people. I have 977 packages and each was built from ports and for many of the ports I have non-default make configs.
I'm also not going to do anything individually for ports with obsolete options, I prefer to work only with sets of ports (read next about portmaster).

"Many" could be 20. 20 of 977 is manageable especially when it's a one-time "set and forget".
Using the redundant-opt-files.sh script makes it trivial to identify these and save them on a list.

That's the most important thing, that you, unfortunately, don't seem to take into account: we don't live in a stasis, the time flows and the ports in the repository do evolve. And they get new config options and lose the old ones.

Huh? As I already said, if the options change, Synth stops and tells you that and makes you fix them. How is what you said relevant?

So from time to time I have to re-configure the ports that were configured once already. And that's normal.

right, normal. And not that frequent.

Unlike synth, portmaster shows make config screen once it figures out that my current config for a port is outdated.

WRONG. Synth tells you when the options are outdated. You're spreading misinformation.

Portmaster is even smart enough as to scan all ports configs prior to starting upgrading them, so currently I run portmaster first to check if there any new configs that require my attention, then I have to answer 'nay' to the prompt that asks to confirm the upgrade to the following ports and run synth.

What's your point? Synth does that too. How do you think it is able to stop and say "fix the options" ?

I would use synth way less frequently (only for the ports that portmaster fails to build) if synth didn't have such an attitude that it has to re-build every port that was built outside of it. I hate that.

That's just a side effect of not understanding how ports and package really work.

No, that's some misunderstanding on your side.
make.conf provides a way to override future prompts with a pre-defined decision.
What if 2 ports have the same license and I'd like to accept it for port A and reject for port B?

You're beef is with the ports system then. accepting a license is not a per-port thing, it's a per-license thing. Reasonably if you accept the license on one port, you accept it for all. You can control the build of ports in other ways, e.g. DON'T PUT IT ON THE BUILD LIST.

You could say that it is some idiocy, while it's actually not at all: port B's older version may have not required to accept a license, but newer versions do.
I might want say 'screw you, dear developer, I'll wait for a fork of the old version', but your approach doesn't leave me such freedom.
You kill freedom with your approach.

Again, direct your derision where it belongs, the ports collection. Synth is just following the directives its has been given.

Again, I don't want to configure everything proactively, I prefer minimal interaction to take place when needed.
Why do I have to check the options prior to upgrading? Why can't the machine do this work for me and ask for my interaction when it needs the human to make some decision? I want that. I want my life to be simpler rather than more complex in such things.

Nobody said you had to. The ports system is designed around default options. If you don't know exactly why you are changing an option, you'd better not change it. It's not meant for interactive behavior, exactly the opposite. All interactive ports were removed a couple of years ago and new ones banned.

Preferably on a centralized host like github where lots of users already have an account (because otherwise the project will get less attention and feedback as there is the laziness of registering new account vs using an existing one on a well-familiar centralized system).
In an issue tracker with a sane number of non-finished tickets it's quite easy to find whether feature X was discussed already so that more users could voice out.

Synth is developed on Github.

But I don't know why I even explain these basics to you, as it's quite clear that you have a quite hostile attitude towards users of your util and not interested in all that.

You're the one that started blasting without any real knowledge. You didn't even know synth is maintained on github with issue tracking and instructions, yet criticized for exactly not having that. Why should people pay attention with your credibility?

I'm not some crusader, I don't fight for making X be like Y.
I just want max comfort from the use of the tools I interact with.
The comfort in that sense is the balance between ease of use and functionality/configurability.

The tool is what it is. In the case of requests that have been evaluated are not going to come in, you take the tool on its merits or don't use it.

In my opinion, synth has only 2 strong points over portmaster:
- it can build ports in parallel (which is supposed to fasten the build process);
- afaiu, it builds ports in a 'clean environment' - I don't really value this feature very much, as it makes the the building process longer, while it usually is needed only when some conflicts across ports appear.

It has many more than that. And if you don't value a clean environment in every case then you really deserve whatever consequences you get.

portmaster has strong points over synth:
- it knows when to show make config screens and it does show them;

some consider this a negative.

- it builds 1 port faster than synth does (because unlike synth it doesn't build it in a 'clean environment';

maybe technically true but it's usually portmaster cheating because portmaster is too dumb to rebuild dependencies so when it's building 1 port it really should be rebuilding several others. In the true case of single port, the time difference on a modern machine with SSD and tmpfs is negligible. It's only noticeable on very old hardware with low ram and spinning disks.

- it shows accept license prompts (but does it in a stupid [all make config screens are shown before the global building process starts, but accept license prompts appear only when the building queue reaches the current port] and buggy [-a key makes it hang up in background whenever portmaster reaches a port that has accept license prompt] way in some cases).

And synth makes the user notice the license needs to be accepted which lets the port build in the future. What's the real difference?

I want all of those strong points in 1 utility. I don't care about its name.

Well, guess you're going to be perpetually disappointed since poudriere has the same "issues" you think synth has (although poudriere has an option to preconfigure options, but it's not during the run). So there's no existing tool to give you what you want. Do what you have to do.

 

[marino]

Okay, let me fix your problem once and all.
The stated problem is that Synth expects ports to be already configured. It assumes this has been done, but the problem occurs when it has not been done.
Here's a solution for a system that already has packages install. Copy this to a script and run it:

#!/bin/sh

origins=$(pkg prime-origins)

for origin in ${origins}; do
   make -C /usr/ports/${origin} config-recursive
done

That's it. You run that script (as needed, which is rarely) before you run synth.
Alternatively, you could feed a build list of origins into a script if the host system has a different set of packages than desired.
Note that "prime-origins" is a new alias that may have to be copied to pkg.conf from /usr/local/etc/pkg.conf.sample

So that should be simple enough for people that require configuring every port, right?

 

[hrenznaet]

It's an easily proven fact.
Given access to your machine, I could determine exactly which ports you have customized to be different than default options. I am quite confident that number is low.
Don't say "BS" without providing any statistics. You're talking to somebody very familiar with the 28,000 ports the collection. As a 3-year committer to ports and a member of pkgsrc for 2 years longer than that, you're talking against a lot of experience. What resume are you relying on to back up your facts?
"Many" could be 20. 20 of 977 is manageable especially when it's a one-time "set and forget".
...
As I already said, if the options change, Synth stops

ls /var/db/ports/ | wc -l
     243
pkg info | wc -l
     981

243/981=24.8%
I'm quite a newbie and don't really know if /var/db/ports also includes configs identical to default configs for their ports, but that doesn't really matter, it means synth would halt on each of those. This is insane.

Unlike synth, portmaster shows make config screen once it figures out that my current config for a port is outdated.

WRONG. Synth tells you when the options are outdated. You're spreading misinformation.
...
What's your point? Synth does that too. How do you think it is able to stop and say "fix the options" ?

Caught you on b/s again. How is what I wrote can be wrong? Read carefully. Halting upon every outdated option is stupid and non-comfortable, and it is not the same as showing make config screens.

That's just a side effect of not understanding how ports and package really work.

Then how can synth be used so it won't rebuild the ports built with portmaster? Or it can't and it's just another b/s 'point' of yours?

accepting a license is not a per-port thing, it's a per-license thing.

Sorry, didn't know that. Well, then your solution about pre-specifying a list of licenses to accept is an acceptable solution, thanks.

Synth is developed on Github.

And again I'm sorry I didn't know that. Found the link.

In the case of requests that have been evaluated are not going to come in, you take the tool on its merits or don't use it.

I also have a right to whine about how stupid some of your decisions are in my opinion and how I miss those features

It has many more than that. And if you don't value a clean environment in every case then you really deserve whatever consequences you get.

I've mentioned only what I noticed and found valuable (if compared to portmaster).

some consider this a negative.

Well, then I laugh at those some.

And synth makes the user notice the license needs to be accepted which lets the port build in the future. What's the real difference?

The difference is in the level of comfort.

Do what you have to do.

I already do. Suffer and whine.

Copy this to a script and run it:
So that should be simple enough for people that require configuring every port, right?

No. Because it's a stupid script: it will show make config screen for each of the configurable ports from the list of installed.
While I need to get a bunch of make config screens only for the ports with outdated configs. That's why my current alias for updating ports contains a portmaster call first before calling synth. I know it's a bit barbarian, but that's the only way to get both utils' strong points.

Sorry, that's probably my last reply in this thread, because looks like you aren't going to conform and thus arguing with you is counter-productive.
Sorry if you found some of my accusations to harsh, I'm a newbie but I value my own preferences in which I find comfort. Your preferences are just not for me.

 

[marino]

ls /var/db/ports/ | wc -l
I'm quite a newbie and don't really know if /var/db/ports also includes configs identical to default configs for their ports, but that doesn't really matter, it means synth would halt on each of those. This is insane.

Yes, the vast majority are identical to default and could be removed. Why would it "halt on each of those" ?
It only halts when the config is BAD. The existence of a valid config will not halt it.

Caught you on b/s again. How is what I wrote can be wrong? Read carefully. Halting upon every outdated option is stupid and non-comfortable, and it is not the same as showing make config screens.

It's wrong because it's wrong. It lists *ALL* bad configs, not one at a time.
This is a good thing. Note that neither portmaster nor poudriere detect bad configs, they just take them. That's unacceptable actually.

I also have a right to whine about how stupid some of your decisions are in my opinion and how I miss those features

Calling me stupid signals the end of the subtopic.

No. Because it's a stupid script: it will show make config screen for each of the configurable ports from the list of installed.
While I need to get a bunch of make config screens only for the ports with outdated configs. That's why my current alias for updating ports contains a portmaster call first before calling synth. I know it's a bit barbarian, but that's the only way to get both utils' strong points.

I can think of 5 ways to make the script a whole of better. The point is that I did that in about 20 seconds.
If somebody comes up with perfect script, I'll be happy to post in the FAQ with acknowledgement.
You missed the point that if if synth expects the ports to be preconfigured, it's easy to script.
And you really , really missed that it's pretty much an up-front thing. You don't keep doing it.

Sorry, that's probably my last reply in this thread, because looks like you aren't going to conform and thus arguing with you is counter-productive. Sorry if you found some of my accusations to harsh, I'm a newbie but I value my own preferences in which I find comfort. Your preferences are just not for me.

Great! Again, I don't get paid for each user so I really don't care if you use synth or not. You paid nothing for it. I think your "right to complain" is pretty limited. I'm happy not to hear it anymore, especially after several solutions to you main issues were provided.[/code]

 

[hrenznaet]

'synth upgrade-system' just uninstalled libreoffice for me.
I didn't ask for that, this is ridiculous.
I think it's time to try poudriere.

 

[cbrace]

Can someone suggest a way of upgrading from php56 to php70 using synth?

I tried deleting php56 and all the php56 extensions with pkg, installing php70 with synth, and then installing www/zenphoto/ www/joomla3/ mail/roundcube mail/postfixadmin www/nextcloud databases/phpmyadmin, also with synth.

However, in doing so synth removed php70 and reinstalled php56 and everything all over again.

Thanks for pointing me in the right direction.

 

[marino]

cbrace@,
Did you create /usr/local/etc/<profile>-make.conf ? (LiveSystem-make.conf by default) ?
IIRC the default version of PHP is 56, so unless you specifically set the version to be 70, php56 is going to be built by default.
If you had that in /etc/make.conf, note that this file is NOT used by Synth. Each profile has its own, optional, make.conf.

 

[cbrace]

Hi marino

OK, I created the profile and added this line:

DEFAULT_VERSIONS+= php=70

and activated the profile in synth configure.

But when now I run synth upgrade-system, nothing gets rebuilt.

If I I install www/php70, all the installed php-based packages are removed. If I try to reinstall www/joomla3 etc php70 is removed and php56 reinstalled.

I still seem to me missing something here. Any ideas?

 

[marino]

when you say you "created the profile", did you mean you created the *-make.conf file?

My guess is that you messed the file name up.
The way you check is to look at any of the build logs. There's a section that list out the builds's make.conf and any customized entries should be in that section. If it's not, the profile makeconf doesn't exist.

So I think you didn't do it correctly. Any new buildlog will confirm.

 

[fernandel]

Hi marino

OK, I created the profile and added this line:

DEFAULT_VERSIONS+= php=70

and activated the profile in synth configure.

But when now I run synth upgrade-system, nothing gets rebuilt.

If I I install www/php70, all the installed php-based packages are removed. If I try to reinstall www/joomla3 etc php70 is removed and php56 reinstalled.

I still seem to me missing something here. Any ideas?

For example, I have:
/usr/local/etc/synth/LiveSystem-make.conf
and it works.

 

[bhtooefr]

For what it's worth, just used synth on my FreeBSD 10.3 system, to install graphics/mesa-libs (due to the port consolidation, after noticing that synth skipped those ports due to them being deleted - and no, I never saw anything in pkg updating about it), and this happened:

Installed packages to be REMOVED:
        cairo-1.14.8,2
        tex-web2c-20150521_1
        cups-filters-1.13.5
        gtk-update-icon-cache-2.24.29
        fltk-1.3.3_4
        libglapi-17.0.3
        poppler-0.50.0
        poppler-utils-0.50.0_1
        vim-8.0.0596
        pango-1.40.4
        qt5-gui-5.7.1
        gtk2-2.24.31
        qt5-webkit-5.7.1
        qt5-widgets-5.7.1
        qt5-help-5.7.1
        qt5-assistant-5.7.1
        qt5-printsupport-5.7.1
        virtualbox-ose-5.1.22
        qt5-x11extras-5.7.1
        fldigi-4.0.3
        librsvg2-2.40.16
        ImageMagick-6.9.6.4_2,1
        poppler-glib-0.50.0
        libGL-17.0.3
        gbm-17.0.3
        libEGL-17.0.3
        libGLU-9.0.0_2
        sdl-1.2.15_7,2
        freeglut-3.0.0
        qt5-opengl-5.7.1
        harfbuzz-1.4.6_1
        qt5-quick-5.7.1
        qt5-designer-5.7.1
        qt5-uiplugin-5.7.1
        qt5-uitools-5.7.1
        qt5-linguist-5.7.1
        hpijs-2.1.4_11
        classpath-0.99_3
        flrig-1.3.30

New packages to be INSTALLED:
        mesa-libs: 17.0.4 [Synth]

And, no, it didn't reinstall the uninstalled packages that depended on the mesa libraries afterwards, so I'm having to do that manually. Can synth be made to handle that situation more cleanly? (Maybe somehow detect when it's replacing packages that depend on something, and offer to rebuild the depends?)

 

[marino]

I think adding an "upgrade system" wrapper for pkg(8) was ultimately a mistake.
Synth isn't doing that. Pkg(8) is.
Presumably the local repository is incomplete or getting confused with FreeBSD official repository.
Most of the issues we've seen are people issuing "synth upgrade system" and just trusting every package is flawlessly built and then an unattended upgrade occurs.
Best practice dictates that A) the root user verifies every package was indeed rebuilt without skips before the repositiory is created and B) probably pkg(8) should be called instead of Synth at that point. The "convenience" command wrapper seems to lead some people astray and I regret adding it at this point.

To circle back: if those packages to be removed were in the local repository, they would be upgraded, not removed.

conclusion: Despite what early document says, probably nobody should use the "upgrade system" command. Definitely they should not use it for snafu's like fixing mesa libs which is completely messed up so suspicions about issues should be high (meaning do NOT upgrade system unattended which upgrade system does)

 

[bhtooefr]

In this case, it was a synth install graphics/mesa-libs that did this, by the way. (In fact, it was an upgrade-system run that failed (for another unrelated reason) that led me to do that.) But, looks like synth build graphics/mesa-libs would've been the safer way to go.

That said, I feel like the older package management tools were cleaner about this kind of scenario (at least when pkg updating actually told you to do the rebuild, and I don't recall ever seeing packages get deleted unexpectedly with portmaster builds). And, the convenience features feel like they're supposed to do the right thing more automatically than they do...