Date: Tue, 26 Jul 2011 11:27:56 +0200 From: Michel Talon <talon@lpthe.jussieu.fr> To: freebsd-ports@freebsd.org Subject: Re: Time to mark portupgrade deprecated? Message-ID: <20110726092756.GA90978@lpthe.jussieu.fr>
next in thread | raw e-mail | index | archive | help
Jerry wrote: > While we are on the subject of port management tools, I still use > "portmanager" when a version bump on a port requires that a massive > number of dependencies be rebuild. I have had all too many instances > when both "portupgrade" and "portmaster" simply bombed out and left me > with only a partially updated system, and in many cases, a virtually > useless one. Portmanager would simple get the job done right the first > time. It might be overkill for one or two port upgrades; however, it > works fine on massive projects that seem to bewilder the other two > competing contenders. The "p5-libwww-5*" example in the case of > "portmaster" being a perfect example. This subject of port management tools is a subject i have been much interested in some years ago, and i must say that the problems which seem to surface now in the general consensus, i had discussed them without any echo at the time. Having a system partially updated hence requiring a lot of work to fix with portupgrade happened to me several times. Horrific slowness of portupgrade was perfectly obvious years ago. I think most of the problems come from errors in the ports themselves so are unfixable through ameliorations in the upgrade tools. I think only a more rigorous management of the ports, i mean something like the separation between unstable, testing, stable in Debian, with rigorous procedures for going from one state to the better one could cure this problem, but at the expense of slowing the development. More importantly, only a procedure centered around *binary* packages could possibly lead to a guaranteed decent state of the ports. Centering things around source code can only lead to confusion, incessant messing by both developers and users with various options etc. which can only destabilize the system. Anyways, to come back to port management tools i don't know how portmanager works, but i think that both portupgrade and portmaster have a fundamental flaw in that they both work locally, upgrading one port after another until the job is finished, which means that the state of the machine is constantly modified, possibly into a broken state, without any possibility for the user to know beforehand that he is headed to failure. A proper tool should do a first pass describing exactly the initial state and the final state so that the end user can choose to upgrade or not. This is what Debian apt-get (or aptitude) does, it describes before any destructive action begins what will be removed, what will be installed. This can only work reliably if you have binary packages, otherwise you can never be sure that a source port will compile. The only *BSD i am aware of that has moved in that direction is OpenBSD. From what i hear, people are happy with the management of ports in OpenBSD, while most of people i hear are very unhappy with FreeBSD ports. -- Michel TALON
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110726092756.GA90978>