I have never had an issue with synth. The times I used it, it worked very well. My use case was ports on a desktop so perhaps not everyone’s situation.
Development here.Take a look at the source code forsynth
-- I've seldom seen such clean and beautiful code. Even if developers do prefer to build with thepoudriere
script (and use jails instead of null mounts to allow building malicious/bad-actor ports) every programmer could benefit from learning a little bit from synth's Ada code. It is really sweet. And I have to add that I've seldom seen any package receive such good support assynth
does here. Mention any problem withsynth
and the author will be show up as if by magic to help...
(Synth is the most straight-forward replacement for portmaster:
Code:synth configure synth upgrade-system synth install <port>
LARGE_FILE
poudriere
can make an local customized repository to me instead use the default pkg from FreeBSD main server, will be a time save. (Read will compile only one time with my custom options, and the update will be deployed to both servers) portmaster
on the webserver scenario, I have the workaround: pkg
version and compile one of the biggest dependencies... pkg
version downloaded before to fill the requirement, and now compile it from source... pkg
will fix the issue... poudriere
will work on previous scenario? portmaster
I was able to get the things up and running. poudriere
can solve the chicken egg problem, so it's the awesome solution... poudriere
fails on my test, there no way instead back to portmaster
and schedule the recompilations because updates...I disagree.Poudriere to me would make sense if you want one build machine to provide packages for many machines which are duplicates of each other, so by duplicates I mean same packages installed, same OS version, same port options and same cputype.
People who do not use Portmaster should refrain from giving advice regarding the use of Portmaster.
Should I be using a different build tool to make this more bulletproof?
I am also grateful there are soo many useful tools to manage ports which facilitate automating updating several installs.
I do not like the black&white attitude “poudriere is the only correct way to build ports,
I’m also one of those who prefer to not use poudriere (nor synth). It has no advantages for my workflow and the way I use the ports.
Please stop creating confusion by quoting partial sentences from different threads. My remark that you quoted (partially) was in response to someone who hijacked that other thread in a non-constructive way, and my response was meant to actually support the original poster. You are misrepresenting the facts.Last I checked we are here to try and help each other in a constructive way. What someone "likes" is up to them to post on their posts. To hijack someone else's question with noise about what someone likes is far less helpful or constructive than offering an option to the original poster based on his own question of what other options are available.[
Yes, that was in fact my intention. My observation is that portmaster causes more bad than good, espc. for newbies. That's why I wanted a thread where the interested newbie can read about the pros & cons and take an informed decision.On the other hand, let me remind you of the topic of this thread: “Do not use ports-mgmt/portmaster and other tools who build in the main system”. This is a quite confrontational thesis. It’s no surprise that it provokes a debate like this.
I have been using portmaster on multiple machines on a daily basis for years now and I can say with confidence that it has done me a lot of good, especially considering the nightmares I was having using portupgrade before that. The use of ports over packages is probably something for more advanced users, but that is not something caused by whatever tool you use to update your system from ports, this is by nature of ports. Anyone who decides to use ports instead of packages probably has a reason to do so, otherwise he/she would not even consider it worth the additional time and effort to do so.Yes, that was in fact my intention. My observation is that portmaster causes more bad than good, espc. for newbies. That's why I wanted a thread where the interested newbie can read about the pros & cons and take an informed decision.
To build (a non-trivial large number of) ports on the host requires that the admin is able to cope with issues that will eventually arise, i.e. mainly the so-called dependency hell:I have been using portmaster on multiple machines on a daily basis for years now and I can say with confidence that it has done me a lot of good, especially considering the nightmares I was having using portupgrade before that. The use of ports over packages is probably something for more advanced users, but that is not something caused by whatever tool you use to update your system from ports, this is by nature of ports. Anyone who decides to use ports instead of packages probably has a reason to do so, otherwise he/she would not even consider it worth the additional time and effort to do so.
While I do not deny that the scripts & tools to assist building ports on the host work sometimes & save a few keystrokes, your post is one of a few pro-portmaster(8) posts that honestly tell about the fact that this method has inherent issues. Most others do not come up with arguments other than "Don't tell me how I have to administer my system" & "portmaster served me well for decades", while at the same time embezzling the issues they had to solve manually. Please note that I'm not talking about building, say, a dozen of ports, but e.g. a GUI and/or the version mismatch (latest ports vs. quarterly packages) you'll run into when building a few selected ports yourself on a system otherwise installed with packages from the official repository.[...] I have been using the ports tree (and portmaster/portupgrade) almost exclusively from the very beginnings and never had any major headaches I wasn't able to somehow solve by myself. When stuff breaks it is often due to software X version B using a header file or library that software X version A installed on the system, instead of using the correct version that comes bundled with the source. Of course a clean room environment would circumvent such problems, but that is hardly a solution to the problem in itself.
No, because there are obviously very few reasonable pro-arguments to build (a non-trivial large number of) ports on the host unjailed.But that aside.... don't you think a thread with such particular title leaves little room for any pros or informed decisions?
The word “sometimes” is a misrepresentation. Do you have any numbers to back that claim? I dare to say it works fine most of the time. I can back that with numbers from my workstation (see below), which is not representative, but not an uncommon kind of setup. Problems caused by ports accidentally using files installed by unrelated ports are a rare exception, not the rule.To build (a non-trivial large number of) ports on the host requires that the admin is able to cope with issues that will eventually arise, i.e. mainly the so-called dependency hell:
While I do not deny that the scripts & tools to assist building ports on the host work sometimes
When I was new to FreeBSD, I tried to build a KDE desktop plus some utilities (avg. workstation use-case) and failed, and I ran into the version mismatch between latest ports tree vs. quarterly packages when I tried to build selected ports with options different from the defaults. Both issues were not clearly covered by the handbook.The word “sometimes” is a misrepresentation. Do you have any numbers to back that claim? I dare to say it works fine most of the time.
The correct build order should be figured out by make(1). While I've been critizising recursive make often, I realize that the ports(7) tree as a collection of 3rd party source trees is inherently restive to declare all inter-port dependencies correctly. Even if it's theoretically possible, there will always be human flaws since naturally the ports tree is a moving target.[...] This is easy to workaround once you’re aware of it, for example by simply adjusting the order of ports while (re-)building.
File in a bug report and flag it wishlist or enhancement or such? For shure an option to build chroot(8)'ed or jail(8)'ed would make perfect sense.(My own update script supports the option to build in a jail, only for those few ports that need it. It would probably be a good idea if the portmaster author added such a feature, too. It’s actually not very difficult at all.)
I see. You are right, mixing latest ports with quarterly packages is a mistake that often leads to pain and suffering. I agree that the Handbook should contain a big fat warning not to do that. (Actually I thought it did, but apparently it doesn’t, unfortunately.)When I was new to FreeBSD, I tried to build a KDE desktop plus some utilities (avg. workstation use-case) and failed, and I ran into the version mismatch between latest ports tree vs. quarterly packages when I tried to build selected ports with options different from the defaults. Both issues were not clearly covered by the handbook.
Yes, when building a single port (plus its dependencies), that works very well. Otherwise tools like poudriere would have the same problem, because it also relies on the Makefiles of the ports collection.The correct build order should be figured out by make(1).
It’s a good idea, but I’m not using portmaster myself, so I have little incentive to spend time with that. (I have to admit this is a selfish attitude, but the day has only 24 hours, so I have to set priorities.)
My workstation has 828 packages installed as of now, all built and updated (yes, using portmaster) exclusively from latest ports, usually on a daily basis. Yet I would not want to go as far as to call it a dependeny hell.To build (a non-trivial large number of) ports on the host requires that the admin is able to cope with issues that will eventually arise, i.e. mainly the so-called dependency hell:
Updating my systems using portmaster has worked for me more than just sometimes and also saved more than just a few keystrokes. Back in the day when I started using 386BSD 0.1 I believe there wasn't even anything remotely like ports. The usual procedure to install some piece of software was to download the source .tar.Z file, extract it, read and follow the instructions in some README file (if there was one) and hope for the best. Failing that either fix the source manually or complain to the authors. So yes, having ports was kind of a quantum leap. Are there problems? Most likely, but none of the problems I encountered recently had anything to do with portmaster in particular, and fell into one of two categories:While I do not deny that the scripts & tools to assist building ports on the host work sometimes & save a few keystrokes, your post is one of a few pro-portmaster(8) posts that honestly tell about the fact that this method has inherent issues. Most others do not come up with arguments other than "Don't tell me how I have to administer my system" & "portmaster served me well for decades", while at the same time embezzling the issues they had to solve manually.
That mixing quarterly and latest is a bad idea is nothing new, but a proven fact, whether you build from ports or use packages. Again that has no relation to portmaster whatsoever. Maybe the handbook and/or other documentation could put more emphasis on this matter if it bothers you that much. Personally I never ran into this issue. As I said, when I started there was hardly any other option but build it yourself, and quite frankly, I wouldn't want it any other way.Please note that I'm not talking about building, say, a dozen of ports, but e.g. a GUI and/or the version mismatch (latest ports vs. quarterly packages) you'll run into when building a few selected ports yourself on a system otherwise installed with packages from the official repository.
Some weeks ago there have been issues with the speed on pkg and/or long unfixed vulnerabilities or so. I do not remember the details. I have looked for a work around. At that time I have tried to create a jail and letting portmaster make packages. Fortunately portmaster has the option to use packages for the build dependencies which saves time. Then I could install the packages from the new source if everything went well. After a few days the pkg servers have been back to normal and I did not follow up the method. I switched back to pkg because I can live with the default settings. But with building in a jail the host is not spoiled and nothing can be overwritten or deleted unintentionally (I think so).(My own update script supports the option to build in a jail, only for those few ports that need it. It would probably be a good idea if the portmaster author added such a feature, too. It’s actually not very difficult at all.)
the best we can do is present facts
There is no binary answer to this. Trying to force "Is this right?" patterns is prompting for reactance. You will be shown that there is a "depends on".this is not a question of agreement, but right and wrong
mixing latest ports with quarterly packages is a mistake that often leads to pain and suffering. I agree that the Handbook should contain a big fat warning not to do that.
svnup ports -r
instead of using portsnap.