From owner-freebsd-ports@freebsd.org Sat Apr 14 17:54:02 2018 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71E56F8D16D for ; Sat, 14 Apr 2018 17:54:02 +0000 (UTC) (envelope-from se@freebsd.org) Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8C286CB5F for ; Sat, 14 Apr 2018 17:54:01 +0000 (UTC) (envelope-from se@freebsd.org) Received: from fwd38.aul.t-online.de (fwd38.aul.t-online.de [172.20.26.138]) by mailout03.t-online.de (Postfix) with SMTP id B404C422BAF3; Sat, 14 Apr 2018 19:53:53 +0200 (CEST) Received: from Stefans-MBP-LAN.fritz.box (bRY2U+ZCQhR-+nO9YSTCKyikdNEHNwHlq4ypY8EYWtg1AGRnYd8vvtgHKCq1H1EQJd@[84.154.107.172]) by fwd38.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384 encrypted) esmtp id 1f7PN0-1VzQRc0; Sat, 14 Apr 2018 19:53:50 +0200 Subject: Re: Conflicts due to renamed KDE4 ports To: Ports FreeBSD References: <20180414165707.GA83446@troutmask.apl.washington.edu> From: Stefan Esser Openpgp: preference=signencrypt Autocrypt: addr=se@freebsd.org; prefer-encrypt=mutual; keydata= xsBNBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAHNLlN0ZWZhbiBFw59lciAoVC1PbmxpbmUpIDxzdC5lc3NlckB0LW9ubGluZS5kZT7CwH8E EwEIACkFAlhtTvQCGwMFCQWjmoAHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRBH67Xv Wv31RAn0B/9skuajrZxjtCiaOFeJw9l8qEOSNF6PKMN2i/wosqNK57yRQ9AS18x4+mJKXQtc mwyejjQTO9wasBcniKMYyUiie3p7iGuFR4kSqi4xG7dXKjMkYvArWH5DxeWBrVf94yPDexEV FnEG9t1sIXjL17iFR8ng5Kkya5yGWWmikmPdtZChj9OUq4NKHKR7/HGM2dxP3I7BheOwY9PF 4mhqVN2Hu1ZpbzzJo68N8GGBmpQNmahnTsLQ97lsirbnPWyMviWcbzfBCocI9IlepwTCqzlN FMctBpLYjpgBwHZVGXKucU+eQ/FAm+6NWatcs7fpGr7dN99S8gVxnCFX1Lzp/T1YzsBNBFVx iRIBCACxI/aglzGVbnI6XHd0MTP05VK/fJub4hHdc+LQpz1MkVnCAhFbY9oecTB/togdKtfi loavjbFrb0nJhJnx57K+3SdSuu+znaQ4SlWiZOtXnkbpRWNUeMm+gtTDMSvloGAfr76RtFHs kdDOLgXsHD70bKuMhlBxUCrSwGzHaD00q8iQPhJZ5itb3WPqz3B4IjiDAWTO2obD1wtAvSuH uUj/XJRsiKDKW3x13cfavkad81bZW4cpNwUv8XHLv/vaZPSAly+hkY7NrDZydMMXVNQ7AJQu fWuTJ0q7sImRcEZ5EIa98esJPey4O7C0vY405wjeyxpVZkpqThDMurqtQFn1ABEBAAHCwGUE GAEKAA8FAlVxiRICGwwFCQWjmoAACgkQR+u171r99UQEHAf/ZxNbMxwX1v/hXc2ytE6yCAil piZzOffT1VtS3ET66iQRe5VVKL1RXHoIkDRXP7ihm3WF7ZKy9yA9BafMmFxsbXR3+2f+oND6 nRFqQHpiVB/QsVFiRssXeJ2f0WuPYqhpJMFpKTTW/wUWhsDbytFAKXLLfesKdUlpcrwpPnJo KqtVbWAtQ2/o3y+icYOUYzUig+CHl/0pEPr7cUhdDWqZfVdRGVIk6oy00zNYYUmlkkVoU7MB V5D7ZwcBPtjs254P3ecG42szSiEo2cvY9vnMTCIL37tX0M5fE/rHub/uKfG2+JdYSlPJUlva RS1+ODuLoy1pzRd907hl8a7eaVLQWA== Cc: Steve Kargl Message-ID: Date: Sat, 14 Apr 2018 19:53:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180414165707.GA83446@troutmask.apl.washington.edu> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ID: bRY2U+ZCQhR-+nO9YSTCKyikdNEHNwHlq4ypY8EYWtg1AGRnYd8vvtgHKCq1H1EQJd X-TOI-MSGID: 516bc06b-0f52-45ec-af3f-4b6bd8d71d23 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Apr 2018 17:54:02 -0000 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