Date: Sun, 5 Apr 2020 15:40:22 +0200 From: =?UTF-8?Q?Stefan_E=c3=9fer?= <se@freebsd.org> To: freebsd-ports@freebsd.org Subject: Re: qt5-webengine Message-ID: <da0d9053-7f0c-36b7-4137-f01504c5d9d0@freebsd.org> In-Reply-To: <20200405005044.GA923@phouka1.phouka.net> References: <20200404101044.76e34919@dismail.de> <20200404142103.GA74752@elch.exwg.net> <20200404111553.6511f6ac@dismail.de> <20200404173325.6b156762@DaemONX> <20200404144231.0d05bdf1@dismail.de> <CAJuc1zNPwat8E4d03h=rUVA-Lw0AwqJYC5uSioUjJKRXDHU4HA@mail.gmail.com> <24201.6978.579552.849799@jerusalem.litteratus.org> <20200405005044.GA923@phouka1.phouka.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 05.04.20 um 02:50 schrieb John Kennedy:> The thing that drove me away from portmaster to synth and eventually to > poudriere is incompatible dependencies. I was running into those with just > X11 dependencies (~600 packages in my full port rebuild, so not sure how you > got lucky over that period of time). Now, people keep on fixing portmaster > and fixing dependencies, but at times I would have just been SOL for an > indeterminate period of time. I have for more than 1 year been using a rewrite of portmaster that uses a completely different approach than the official version. But due to "features" of the ports system, that only ever considered whether they might break poudriere (and thus the package build cluster) it is extremely complex to cover all special cases. That version has been tested by a few people that asked, but I have meanwhile given up on trying to get it working perfectly for all cases. The logic is just too complex to express in Bourne Shell or Bash. Main features beyond a better strategy logic is that this portmaster can be used to build in a clean environment (idea stolen from synth) and it can also be used to maintain a repository to upgrade from. I have started porting that version to LUA a few months ago and have been able to update ports with it (with the syntax of the shell version just translated to LUA). Since LUA offers quite advanced features for object oriented or function programming styles, I have then re-implemented layer for layer in a style that uses LUA features. This has also allowed a significant speed-up: Checking my ~2400 ports for missing updates (and I have kept the development system without updates to have a good test coverage) results in 1373 actions (upgrades, new installations) and it takes 50s to get all ports checked and another 10 seconds to identify collisions of to-be-installed dependencies with existing ports. (And with 4 cores this could be reduced to 20 seconds for this large set of ports, but I'm currently trying to get the functionality complete, speed comes as a secondary goal.) > I also got in the habit of rebuilding and reinstalling everything about > once a month because of weird (dependency) breakages that portmaster (at > least at the time) couldn't figure out and recompile itself. I'm tracking not only version changes, but also whether a port relies on an outdated library. It is possible to update all ports that have an OSVERSION from before a kernel change that requires the port to be re-installed (most relevant for -CURRENT). I'm working on this in spare time (too little, currently) and the ports system is not friendly to any tool besides poudriere. The implementation of flavors is particular bad to deal with, if you do not just maintain a package repository, but want to upgrade a system with installed ports to the latest versions (with your options intact). > I'm really impatient, and have a compulsion to security-patch things, so > thus I was finally driven to change (after I don't know how many years). > > Synth and poudriere avoided it because it was a build dependency, not a > run-time dependency, and their build environments kept that very clean > (which portmaster couldn't do, at least at the time). It also let me have > less packages loaded on the machine overall, so less surface area for attacks. > Yeah, it recompiles a BUNCH of things that often don't get upgraded, but I've > never felt the need to recompile everything in case something got missed. It is already possible to install build dependencies from packages saved from a prior portmaster session and delete build tools not required as run dependencies at the end of the portmaster run. This does work with the version in ports. I have added the ability to build in a clean jail with build tools only ever available within the jail during the session. > I also find that port problems that break poudriere builds get caught > quickly (vs more-rare synth problems, and way faster than portmaster), so > I get to reap the advantages of what FreeBSD is building with. Yes, the problem is that only problems that affect poudriere are caught by the build cluster and even port system infrastructure changes may impact tools like portmaster (or portupgrade) in such a way that they completely break. That has been the case with the (IMHO) badly designed flavor support, which made portmaster unusable until I took over maintainership and added flavor support (working most of the time, but not perfect). There have been other changes, like renaming of ports and packages at the same time when KDE4 was removed from ports: This makes it impossible for a tool like portmaster to correctly identify the port directory to use in order to upgrade some installed package - at least one of port origin and package name are needed to perform a match (MOVED could have helped, but it was not used when KDE4 was deleted for reasons that I can understand). Anyway, I'm working on the LUA implementation of portmaster, which will combine features from the current portmaster (ease of use with a small set of packages, fast for testing of port changes) with synth (building in a clean jail) and poudriere (creation of a package repository to upgrade from). I hope that LUA will be accepted as the implementation language, since it is small and available on all relevant platforms (different from synth which is written in Ada). But it will take me at least a few weeks to finish that work. I'm at the point where the required actions are correctly planned, but without conflict resolution logic (e.g., if a port has a dependency on samba and tries to install a conflicting default version while another version is currently installed and well suited to resolve the dependency). Regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?da0d9053-7f0c-36b7-4137-f01504c5d9d0>