Date: Sat, 14 Apr 2018 19:53:49 +0200 From: Stefan Esser <se@freebsd.org> To: Ports FreeBSD <freebsd-ports@FreeBSD.org> Cc: Steve Kargl <sgk@troutmask.apl.washington.edu> Subject: Re: Conflicts due to renamed KDE4 ports Message-ID: <f5e5fc69-c3e5-fbfc-485c-01ed18b0cbbe@freebsd.org> In-Reply-To: <20180414165707.GA83446@troutmask.apl.washington.edu> References: <a9ce1576-a254-4e79-3e50-b90d49827a1e@freebsd.org> <BN6PR2001MB1730DAE90491E510EDED691F80B20@BN6PR2001MB1730.namprd20.prod.outlook.com> <20180414165707.GA83446@troutmask.apl.washington.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f5e5fc69-c3e5-fbfc-485c-01ed18b0cbbe>