Date: Sat, 17 Dec 2016 12:51:42 -0600 From: John Marino <freebsd.contact@marino.st> To: abi <abi@abinet.ru>, "ports@FreeBSD.org Ports" <ports@FreeBSD.org> Subject: Re: The ports collection has some serious issues Message-ID: <b3c3d33c-439f-59cf-fa60-b025428996d4@marino.st> In-Reply-To: <58558519.3080509@abinet.ru> References: <b21222a1-4940-1a44-0693-8c7803798a58@marino.st> <58558519.3080509@abinet.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/17/2016 12:34, abi wrote: > >>> 2. It doesn't provide dialog for port options, so >>> 2.1 I don't receive information if port options have changed. I don't >>> know what else will be pulled to my system after port tree update. >> >> which of course is a false statement. >> If you set port options which then change, Synth will stop and tell >> you to reconfigure or remove the saved port options. > > Not at all. For example, let's assume I go recommended way and have > options for ports with not default settings. Let's say, I have perl with > default options (no OPTIONS file). Let's say port maintainer adds new > option, [NSA Backdoor] > Perl will be silently compiled with that option, right? Yes. If you don't explicitly save the options then Synth has no way to detect a change in options. > This is not paranoia, here is example from real world - I rebuilded one port and > noticed new option - [USE GCC] with default On. I really don't want that > gnu beast in my system, so I investigated the problem and suggested > patch to compile port under clang. Everyone happy. We can search PR > database if you don't believe me. > If I was synth user, I've ended with gcc pulled. If your view of the world means that any or all ports maintainers are out to get you, then yes, I see your problem. There are ways to recursively set every possible option though. You can easily write a script to iterate your build list and recursively check every option using the standard ports framework. If you did that, then synth would detect every option change and stop. > >> >>> 2.2 If I make option files for all ports, synth fails to rebuild >>> repository if port and it's options are out of sync. >> >> yes, of course. If you give it impossible instructions, it will stop >> and ask you to fix them. Any reasonable person would want to be >> informed when the options are incorrect. Did you also notice that >> extended use of portmaster resulted in dozens of obsolete options >> files that you weren't aware of? So your criticism here is that you >> think Synth should just ignore these bad configurations? > No, I didn't notece obsolete options. Maybe my /var/db/ports is a > complete mess and I should cry in tears. but when portmaster encounters > new options it invokes dialog4ports and let me fix the problem. If this > leaves some staled OPTIONS file, I'd say it's portmaster bug, not design > feature. We all know that portmaster is in rather poor shape. The detection of changed options by ports framework doesn't always work. It definitely doesn't work if portmaster is controlling it. You shouldn't rely on this. > First of all, synth ignores /etc/make.conf completely. Yes, we As does poudriere, as it was designed to do. As it should do. > definitely need another place to keep global make options, however > DEFAULT_VERSIONS suggestion is a bad advice here. > Here is example: recently ports framework deprecated perl 5.20 and > switched to 5.24 > portmaster users should recompile all ports depended on perl (from my > point of view this is done not very reliable), but when it comes to new > perl, portmaster will invoke dialog4ports. > synth user with non-default perl options will receive new perl with > default one. I hit this very problem during my synth test when I noticed > pgadmin3 liked to postgresql93-client and added DEFAULT_VERSIONS to 96. synth will rebuild everything that changes as a result of change to [profile]-make.conf as does poudriere. It deletes the obsoleted packages first then rebuilds everything that's missing. It works. If you use "synth status" to give it a build list, of course it's also going to keep building the old perl because you told it to. That's just a convenience command. If you want to be exact, you maintain a discrete build list of the prime ports. When in doubt, you can always remove all and reinstall the prime list after the repository is brought up to speed. That's not necessarily done often, but it is guaranteed to always work. > I see how synth can be used in pkg framework, I even agree that synth is > poudriere done right and I feel I will use synth test feature for ports > I maintain, what I fail to see, how I can use it to keep my laptop > updated. I'm not asking for pony here, the examples I provided (if true) > lead to overcomplexity maintaining packages up to date. I guess it just takes more experience. It's definitely not more complex than portmaster. I would say it's simpler. Plus the fact that portmaster can only build serially while both synth and poudriere build in parallel is a huge advantage to any single system user. John --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?b3c3d33c-439f-59cf-fa60-b025428996d4>