Date: Tue, 26 Jul 2011 13:56:14 +0200 From: Torfinn Ingolfsen <tingox@gmail.com> To: FreeBSD Ports ML <freebsd-ports@freebsd.org> Subject: Re: Time to mark portupgrade deprecated? Message-ID: <CAJ_iqtYvXnQN3iFgEp0OXGdhU8vcKJsiNb84_rp0Mb9f12hc0w@mail.gmail.com> In-Reply-To: <20110726092756.GA90978@lpthe.jussieu.fr> References: <20110726092756.GA90978@lpthe.jussieu.fr>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Tue, Jul 26, 2011 at 11:27 AM, Michel Talon <talon@lpthe.jussieu.fr> wrote: > 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 The subject we were discussing was portupgrade; if you want to discuss something else, please start a new thread. Thank you. > 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. I would say that "most people your hear" isn't a representative subset of all the people who use ports. In my experience anyway. -- Regards, Torfinn Ingolfsen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ_iqtYvXnQN3iFgEp0OXGdhU8vcKJsiNb84_rp0Mb9f12hc0w>