From owner-freebsd-questions@freebsd.org Mon Dec 7 23:20:27 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 640E69D377A for ; Mon, 7 Dec 2015 23:20:27 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: from mail-io0-f193.google.com (mail-io0-f193.google.com [209.85.223.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E9801B10 for ; Mon, 7 Dec 2015 23:20:27 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: by ioef137 with SMTP id f137so637716ioe.0 for ; Mon, 07 Dec 2015 15:20:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=references:from:to:cc:subject:in-reply-to:date:message-id :mime-version:content-type; bh=hjrnI3heOWVA+aBMGFR3WhJ3KR4d4LIKpGf9qgMtoSk=; b=J2fvwQ2m0+OFW2mOKdaaeLVgI4Le7vSGMK3IRzBU4V7zs0GM74z5emzJLv09UKkk2Q R798xn59V++zv86WM+1wKLIW99Edimp8FSFdEewrZdrP9TSXR+94ir+0LfbQtI7pMXeq qfIokJktIZN5NEql1eOguhOFNYIZqgo6/4ICjbmZFK8cFyWegvK/yL7BRrgp69jb7AxG S065OKmAo62koKx5IyzHLikTaaqiY6KvgJB7beIPkiSq0RBiyefKXuWraUkKZgHzRTrb 3XtjlkCgIVU0rYlotWMSsQz4TwHfWcTrXns4lLYWhVZC5yAZhtWNdRWx/qTyHOEBWSYM 9kew== X-Received: by 10.107.28.140 with SMTP id c134mr477847ioc.122.1449521354049; Mon, 07 Dec 2015 12:49:14 -0800 (PST) Received: from WorkBox.Home.gmail.com (63-231-131-191.mpls.qwest.net. [63.231.131.191]) by smtp.gmail.com with ESMTPSA id c5sm155229igg.14.2015.12.07.12.49.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2015 12:49:13 -0800 (PST) References: From: Brandon J. Wandersee To: Paul Stuffins Cc: freebsd-questions@freebsd.org Subject: Re: Migrating to FreeBSD from Debian In-reply-to: Date: Mon, 07 Dec 2015 14:49:11 -0600 Message-ID: <86io4a6l2w.fsf@WorkBox.Home> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Dec 2015 23:20:27 -0000 Paul Stuffins writes: > Hi Everybody, > As 2016 is fast approaching I want to finally move to FreeBSD and stay with > FreeBSD, so my question is, what is the best or most efficient way of > upgrading all ports on a FreeBSD machine? Right, so since this kinda derailed quickly, I'll try to answer this clearly and comprehensively. I moved from Arch Linux to FreeBSD myself just over a year ago, so I'll try to iron some things out for you, since it took me some time to sort all this out myself and I sympathize. The package package manager isn't drastically different from pacman or dpkg/apt, so you should find understanding it pretty easy. Just read the man pages and the relevant section of the Handbook for the basics. Beyond that, though, there are some characteristics of the packages and repository that need to be understood. First, in almost every case a single port is built into a single package with a fairly sane set of default options. Even in cases where multiple versions of an application exist--such as Emacs--there is a corresponding port with a different set of options. So if you're lucky, you'll be able to use packages for everything you need. If there's any application built without an option you want, you'll have to build it from the ports tree. This raises some caveats. For one thing, while packages are built and the repository updated several times a week (up from just two or three times a week when I first started--great work, folks), as of now it's not a continuous process. This means the ports tree (which works by a rolling-release model) is always a few hours to a couple days ahead of what you'll find in the repository, raising the possibility of dependency conflicts if you mix ports with precompiled packages. For another, if you try upgrading your binary packages using `pkg update && pkg upgrade`, pkg(8) will also replace your personally compiled ports with the most recent default versions found in the package repository. There are two ways to avoid these issues. If you just have, say, two or three ports to manage, you can use pkg-lock(8) to prevent pkg(8) from messing with your ports. You can then upgrade your packages as usual, and then use ports-mgmt/portmaster or ports-mgmt/portupgrade to upgrade your ports afterward. This can be a little tedious, as (a) you'd need to use Subversion to synchronize your local ports tree to the revision used to build the most recent set of packages, which must be done manually; and (b) you would need to use `pkg unlock` on your custom package before upgrading them (but *after* upgrading your vanilla packages), and then run `pkg lock` on them again after upgrading. So it would require building some new habits. There are a couple sripts I've seen that are supposed to synchronize your ports to the package repo automatically, but last I checked they hadn't been updated for 10.2 and did not work for -STABLE or -CURRENT. If you have more than a few ports to build, or don't mind waiting a few months between package upgrades (you are a Debian user, after all), you can just use the quarterly repository and ports tree, which are always kept in sync and updated every three months. As of FreeBSD 10.2 the quarterly package repository is used by default on new installs, and fetching the quarterly ports tree with Subversion is easy enough (it's in the same SVN repo as the main ports tree). So this is definitely the easier way to go if you want to mix ports with packages. Of course, if you have lots of ports you want to customize, you might just skip packages entirely and stick with ports. In that case, ports-mgmt/portmaster seems to be the semi-official way of handling things. You'd just run `portmaster -a` to upgrade all installed ports. If there are any new options available in a new version of the port, portmaster will prompt you to check your options interactively before continuing. You could also use ports-mgmt/poudriere to build custom packages into a locak repository; it's the same build system used for the official package repository. Setting it up the first time takes a little work, but it would allow you to build from either the rolling or quarterly ports tree as you see fit, and updating is just a matter of fetching the latest commit of whichever ports tree you're tracking and running the build command. I use it myself, and love it. Poudriere is quicker and more efficient than Portmaster on machines with plenty of RAM and multi-core CPUs. Since the ports system and package manager are tied to each other, once a port is installed you can perform any actions you see fit on it using pkg(8). It's all the same at that point. And as was already mentioned, always make sure to read /usr/ports/UPDATING (or run `pkg updating`) before proceeding to see announcements about any special measures that need to be taken. Hope this all helps a bit. -- ================================================================= :: Brandon Wandersee :: :: brandon.wandersee@gmail.com :: ================================================================== 'A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.' - Douglas Adams ==================================================================