Date: Mon, 30 Apr 2018 22:01:57 +0200 From: Stefan Esser <se@freebsd.org> To: freebsd-ports@freebsd.org Cc: Thomas Mueller <mueller6722@twc.com> Subject: portmaster plans (was: Re: portupgrade vs. portmaster) Message-ID: <7b5364d5-daf3-69ce-f727-a42c52e47441@freebsd.org> In-Reply-To: <20180430113403.AF3FF13BA@StefanEsser.freebsd.org> References: <alpine.BSF.2.21.1804291704260.12803@mail.neu.net> <20180429214807.GA85409@elch.exwg.net> <CAN6yY1t50FOZBSySA9W6c2Tf0aNzj2fB_K6fUKZM_s8bB%2BHMsg@mail.gmail.com> <eb6b5782-83e0-0070-92bf-ff163de8ea3c@freebsd.org> <20180430113403.AF3FF13BA@StefanEsser.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 30.04.18 um 12:33 schrieb Thomas Mueller: > Current portmaster, even before FLAVORS, was clumsy upgrading a large number of ports, especially when there is an upgrade of perl or png. The author of portmaster decided to abort the upgrade of all remaining ports, if any dependency failed for any one port (i.e. did not try to build further independent ports, in that case). Or is there some other problem with e.g. perl upgrades? I plan to introduce new build options, e.g. to rebuild all ports that depend on libraries in some compat directory, or which have installed files in some path (e.g. the perl ports that install in a sub-directory that depends on the perl version). What other criteria might be useful to select ports for upgrading? > I see hardly any mention of synth on the freebsd-ports list. Have synth users become disenchanted? I do not know how much development is occurring for synth. It is written in a language that is only supported on amd64 (and i386?) and I'd rather use a tool that works on all platforms. > One downside is that synth fails to install build dependencies, so I have to pkg install all of these separately, very annoying. Pure build dependencies should not be required on a system, outside the build process. If you need some compiler or build tool, then it is just a normal program selected by the user. > I was bitten just yesterday trying to build cross-compiling tools for Haiku when make info was missing because texinfo was built but not installed. This might be a problem with the specification of dependencies in the port. > But I was able to recover with pkg install after checking my repository. With correct dependencies, this should not have been necessary. > With portmaster, I need to specify ports by category/portname rather than just portname, for example > portmaster www/seamonkey Yes, this is intentional. It could easily be changed, but currently only a parameter with / in it can lead to a new port being permanently installed (instead of as a dependency that might be automatically deleted when no longer required). What is the proposed semantic of a parameter that might select a port origin or some installed package, say if I invoke "portmaster bash" with or without bash being installed? > Will both the old and revamped portmaster be maintained, and what will be the port names, since there can't be two ports both named portmaster? I plan to create a portmaster-devel port, once the main-functionality of the existing portmaster port is complete. That version is meant for testing and as development version for new features. It should replace the current version after a few (say 3 to 6) months of testing. I'm willing to consider feature requests for the new version. My goal for now is to make it automatically deal with situations like the recent KDE4 port and package renaming, but also with scenarios not covered by the current version, where an indirect dependency must be considered. I'd like to implement a feature that builds all ports in a clean environment, as synth does. But this is not a priority, since we have poudriere and that is the official tool to build your own package repository. But a low overhead mode that works without setup effort on a subset of what poudriere offers might be quite useful. (And synth might offer that if it was written in a more portable language and if it was guaranteed to be well supported and maintained over the coming years.) Best regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7b5364d5-daf3-69ce-f727-a42c52e47441>