Am 14.04.18 um 18:57 schrieb Steve Kargl: > On Sat, Apr 14, 2018 at 02:30:09PM +0000, Carmel NY wrote: >> On Sat, 14 Apr 2018 14:18:22 +0200, Stefan Esser stated: >> >> {truncated} >> >>> This is another case (after the implementation of FLAVOR support that does >>> not seem well-designed and causes lots of effort and inefficiencies in port >>> management tools like portmaster), which makes me consider giving up my >>> efforts to keep portmaster alive. >> >> Have you tried using "synth"? > > This discussion occurred with the introduction of FLAVORS, > which broken all ports management tools except poudriere.
Yes, but I put literally hundreds of hours of effort into understanding portmaster (which is one monolythic 4000 line shell script with global state that recursively invokes itself to implement local state, with hundreds of instances forked in practice) and implementing FLAVOR support. That worked, until the next breakage was introduced by port and package renames, that make it impossible to automatically track the history of a port and to upgrade it correctly. While poudriere just rebuilds ports (using available packages to satisfy dependencies) and does not care what dependencies a user has previously used on a system (e.g. which of multiple SSL libraries, for ports that offer a choice). Instead the packages built by poudriere will enforce a certain set of dependencies, giving the user no choice (unless the packages were custom built with specific options). But it seems that the packages built by poudriere are also not suitable for a clean upgrade of installed KDE4 ports. At least in a test run, some 10 KF5 ports were going to be installed during an attempt to upgrade a KDE4 port from an official package. Portmaster was fully functional before this new breakage, and I'm really annoyed, that the KDE port and package name changes have been performed without any thought about the consequences for port management tools. It is possible to work around this problem by manually setting certain parameters in the package DB for each affected port. I had expected that at least a script that perform these operations on the package DB was provided. Now the best option appears to be to remove all installed KDE4 ports and then to rebuild them with portmaster (which will work, but requires a lot of unnecessary effort and time). I'm still trying to find a satisfactory heuristic that lets portmaster DTRT. But this is a problem, since there are situations where one choice of action is correct, while it will lead to corruption of the installed packages in other cases. The problem is, that now there are systems that have KDE4 ports with package names (sans version) and origin identical to KDE5 versions of the respective program (e.g. databases/akonadi used to be a KDE4 port that built akonadi-1.*, now it is a KDE5 port that builds akonadi-17.*, which is of no use on a KDE4 system and not suitable for use with KDE4 ports. Upgrading akonadi (and the tens of other KDE4 ports whose port directory has been hijacked by KDE5 versions) will thus create useless KDE5 versions (and the KDE4 version will be removed when the KDE5 version is installed). Later upgrades of ports that depend on akonadi-kde4 will install the correct new dependency (but are broken up to that point). But the useless KDE5 ports will not be automatically removed. Hmmm, if they were installed as an automatic dependency (and not directly by the user), I could use that as a sign, that no other port depends on them (unless they are actually required by a KDE5 package). This will require extra effort, but I can try whether this works reliably. I'll see whether I find an algorithm that uses information not currently required or used to resolve these cases. But this will only be in a completely new portmaster, which shares just the options processing (to stay as compatible as possible with existing scripts that invoke it) with the current version in ports. Regards, STefan _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"