It was planned some time ago, but versions of Samba older than 3.5 are now out of pkgsrc, and version 3.5 will hopefully be replaced by 4.0 soon. Ruby 3.0 and 3.1 will also be going soon.
If you have git installed, and you are trying to upgrade it, you may have problems. The scmgit-docs package dependency requires some DocBook files that aren’t always accessible. If you do run into this problem, there’s 3 separate options:
- You can just install scmgit-base and ignore scmgit-docs. The program ‘git’ still runs.
- You can download the prebuilt DocBook files separately.
- You can rebuild some XML-related dependent files and then rebuild without issue.
Hubert Feyrer wrote a review of Ansible 0.9, a management tool for multiple systems, similar to Puppet or maybe Chef. Just after doing that, Ansible 1.0 came out, with support for pkgsrc via pkgin-installed packages. This is the first solution (that I know of) that supports pkgsrc package management for multiple systems.
John Marino’s DPorts project, mentioned here briefly before, is interesting. I had two separate people ask me how it works, so a better explanation is in order. I’ve tried it out on a test machine over the past few weeks.
Background:
Dports is an effort to use FreeBSD’s ports system as a base for DragonFly, and the pkg tool as a way to manage binary packages built from DPorts. This is complicated, so I’ll explain each part in order.
- FreeBSD ports are a FreeBSD-specific collection of software installation files that automate building 3rd-party software on FreeBSD. You’ve probably already heard of them. (Note there’s no mention of DragonFly.)
- DPorts is a collection of files that map to existing FreeBSD ports, and contain any changes necessary to make that port also build on DragonFly. Many of those programs build without changes on DragonFly. DPorts builds from source.
- pkg is used for package management, and is usable on FreeBSD and on DragonFly. The binary packages produced from building with DPorts can be installed from remote locations and managed separately using pkg, so that software upgrades and installation can be performed with binaries only. (It’s much faster that way.)
Every port seen in DPorts is known to build on DragonFly. John Marino adds a port only after it builds successfully, using poudriere as a bulk software tool. Ports are only updated to a newer version when that newer version builds, too, so once something arrives in DPorts, it should never break from being updated at some point in the future.
Installing:
To use DPorts, you need two things:
- DragonFly 3.3 or later, though 3.3 is the most recent right now.
- You need to rename /usr/pkg so that your existing pkgsrc binary programs don’t get accidentally used while working with DPorts, causing confusion. If anything goes wrong with DPorts when you are installing it and you want to go back, remove all the DPorts packages and rename /usr/pkg back to normal.
(Don’t confuse pkg, the management tool, with /usr/pkg, the normal installation directory for pkgsrc. ) For the installation of the base port files:
cd /usr make dports-create-shallow
If you’ve already renamed your /usr/pkg directory, git won’t be in your path any more. You can instead download a tarball and unpack it, which also happens to be possible automatically via that same Makefile.
cd /usr make dports-download
Downloading via git is fastest, so if you do need to use the tarball via make dports-download, build devel/git, delete /usr/dports, and then pull it again with make dports-create-shallow. This all comes from John Marino’s Github site for DPorts.
Managing DPorts
DPorts doesn’t use pkg_info, pkg_add, and the other tools traditionally seen on DragonFly for pkgsrc. Instead, package management is done with pkg. Use pkg info, pkg install, pkg remove, and pkg update to list, install, delete, and upgrade various packages on your system. Packages built from source or downloaded as prebuilt binaries are managed the same way, using these tools.
See some of the other writing about pkg for FreeBSD for details on how it works.
Since DPorts doesn’t update a package until it gets a successful build, and installations are of successfully built binary packages, upgrades with prebuilt packages should always succeed. Since they’re binary, they should be fast. There’s a lot of ‘shoulds’ in this sentence, but these are reasonable suppositions.
What about pkgsrc?
Pkgsrc and DPorts shouldn’t be used at the same time, since one system’s packages may be at different versions but still get picked up during building for the other system. That’s about it for restrictions.
I intend to try building an experimental release of DragonFly with DPorts, to see if all the right packages can be added, but no guarantees. DPorts is brand new and does not yet have a repository for downloading packages, so the normal caveats apply; don’t install it on a mission-critical machine, and be ready to deal with any surprises from using it if you do try it out.
What packages are available?
Browsing the Github repo will show you all listed packages. More complex packages like xorg, openjdk7, and libreoffice install, as does xfce. Parts of KDE 3 and KDE 4 are in there. (I haven’t tried either.) I’m not sure about Gnome, but I don’t think anyone ever is. There’s no vim, but there is emacs.
That’s just what I see at this exact minute. It changes daily as more packages are built. Changes from DragonFly builds are sometimes relevant to the original FreeBSD port, so there’s benefits for everyone here.
What next?
Try it now if it has all the packages you need, or wait for a binary repository to be created to speed things up. Remember, this is a new project, so a willingness to deal with problems and contribute to fixes is necessary.
It’s actually been out since the start of January, but the release announcement is available now.
John Marino has been working for some time on a project he calls, ‘DPorts’. You may have noticed his recent commits for it. He wrote up a summary on users@ to explain what he’s doing. It’s translating FreeBSD ports to DragonFly in a way that appears to be (relatively) low-maintenance. It only works on DragonFly 3.3 and up and you can’t use it at the same time as pkgsrc.
Most interesting to me, it gets rid of the quarterly release chase that happens with pkgsrc releases. Since it’s primarily a binary install system, packages are only upgraded when the results are known to work.
Will you be near Berlin, Germany, in March? The pkgsrccon 2013 technical conference will be held there. Julian Djamil Fagir posted details about the event. The conference is free; you pay for your food and drink. If you’re interested in presenting, you need to contact them before March 8th.
As is customary with pkgsrc, a number of packages that do not build or are no longer needed will be removed. This will happen in the next quarterly release. It’s a short list, and one item on that list, misc/p5-Locale-Maketext, will actually stay.
The freeze for pkgsrc-2012Q4 is due to complete in about 48 hours.
The Digest was down over the last 12 hours or so – sorry! Upgrading this system took a bit longer than planned. I upgraded to Apache 2.4, and had to figure out all the config changes, and several packages didn’t like upgrading.
I’ve resisted upgrading for a long time, mostly because I think I could recreate the entire Apache 1.3 config file layout from memory. For the benefit of anyone else, this checklist of Apache errors and corresponding modules helped tremendously. Also, pkg_leaves is a great, if minimal, way to find packages you don’t need.
Pkgsrc has entered a ‘freeze’ for their next quarterly release, which would be pkgsrc-2012Q4. (DragonFly 3.2 ships with 2012Q3) The freeze ends and the release happens at the end of the year, assuming no surprises.
If you were thinking you wanted to try gcc 4.7 with pkgsrc, John Marino’s described the option you need to set. It only works in pkgsrc-master right now (because of changes John made), and not every package in pkgsrc will build.
The advantage is that it’s also possible, with the same syntax, to set pkgsrc to build with gcc 4.4. This means the default compiler in DragonFly can be changed to gcc 4.7 and pkgsrc packages that aren’t compatible can still be built.
Update: Check this minor change: ‘?=’ instead of ‘=’.
If you’ve ever wondered how building all of pkgsrc would go with GCC 4.7.2, which is in DragonFly but not the default compiler, John Marino can show you just that. He has a list of the results from a bulk build of all packages on DragonFly with GCC 4.7.2.
The initial download of pkgsrc via Git on DragonFly is a little bit faster now, with the ‘make pkgsrc-create-shallow’ option recently added by John Marino. Note that there’s a similar option for src. It skips downloading file history.
On the 10th of November, I’m going to remove the binary pkgsrc packages from mirror-master.dragonflybsd.org for DragonFly 2.8 through 2.11. They are closing in on 2 years old at this point, and are from a pkgsrc branch that hasn’t been updated for that long.
If you are actually using version of DragonFly that old, you can continue building from pkgsrc normally; these are just prebuilt packages.
A thread on pkgsrc-users@ reminds me: adding a specific line for bin-install will save time when rebuilding packages; pkgsrc will use existing binary packages instead of rebuilding from source when possible, when this is set. At least, I’m pretty sure that’s what it does.
John Marino did a bulk build of pkgsrc using gcc 4.7.2, and posted the results. The result? About 1% of packages that built with gcc 4.4 did not build with 4.7.2. Whether that’s a problem with gcc or a problem with how each of those software packages were created by the original authors, I don’t know.
I’m planning for DragonFly 3.2 to come with pkgsrc-2012Q3, the most recent release. I’m building binary packages to match, and the build should complete by the time we release on the 22nd…
Notice I said “should” – sometimes the universe conspires against bulk builds.
DragonFly 3.2 branches tomorrow if all goes to plan. Until then, I have a lot of reading here for you.
- Winners of the International Obfuscated C Code Contest for 2012. (via) The winning entries don’t appear to be listed yet, but you can look at previous years.
- “At often, the goat-time install a error is vomit.” (via)
- This makes the D&D player in me take notice: A set of 12 sided dice that never tie. You can buy them, along with a bunch of other custom dice, right from the maker. (also via)
- “To understand the command line…” There’s some good UNIX history notes in there. Don’t hold the ‘User Friendly’ cartoon image against the author. (via)
- Dan Langille does it right when figuring out where his disk space went.
- Monthly Catonmat geek T-shirts. I know, I know, the last thing the world needs is more nerdshirts, but I like the first one on offer.
- Images to make perfectionists suffer. At first I laughed, and then I started to get irritated. (via)
- This networking change in Linux just makes me feel icky. (via ftigeot on #dragonflybsd)
- An Interview with Brian Kernighan on C and the C Programming Language. (via)
- Statistics from 777 .vimrc files. (via) Hover your mouse over the ‘sparkline’ graphs for more information. That’s a very slick way to get more information into a small space. It also led me to this wonderful Solarized colorscheme.
- OCaml 4 will show up in pkgsrc soon.
- Bob Bagwill got DragonFly added on AlternativeTo.net.
- I link to this step by step sed explanation because I found it useful, and because it has this “perverse” example:
sed '/^g/s/g/s/g'
- The “dragonfly issue“. (thanks, Dean.)
- The Hall of Unwanted Dotcoms. Some of these are just fun to say. (via)
- 20 Years of Thinkpad. I have a Thinkpad x220 for work and I like the way it’s built far more than any other laptop I’ve dealt with.
Your unrelated link of the week: Dog Shaming. I have a parrot, rabbit, and lizard. They seem like easy, normal pets compared to some of these stories.
I mentioned open-sourced CDE here before, but it makes me happy to see someone planning to do a bunch of work on it that will hopefully make it upstream, and specifically include DragonFly.
David Shao posted a nice writeup of what works and what does not for DragonFly as a desktop, from pkgsrc. It actually sounds pretty good other than issues with a recent cairo update that I think affected multiple platforms.