mjollnir, I basically agree with most of what you wrote (with minor disagreement in some details, but that’s really not that important).
Just some notes and additions …
Nothing, except that the defaults present a pitfall for newbies: the version mismatch of
ports(7) tree (
latest branch) vs. packages (built from the
quarterly branch). The (bad) consequence is that dependencies will be pulled in from another branch when you start to build a single software package from ports on a system installed from binary packages.
Yes, I agree, those defaults can cause trouble. This is why newbies are told to
not mix ports and packages (and this is pretty much independent from the tools you use, whether portmaster or something else).
Those defaults have historic reasons. The concept of quarterly branches is relatively new – Not too long ago there was only “current” ports (a.k.a. “head”). Shortly after the quarterly branches were introduced, the decision was made to use them by default for the package repository of new releases, because they were assumed to be more stable than “head” and in a more consistent state, and therefore newbies would have less problems with them. On the other hand, portsnap continued to only deliver “head” – partially because of technical reasons (without major changes, portsnap itself and the infrastructure behind it were not able to handle multiple branches), partially because people who decided to use portsnap and build from the ports collection themselves were assumed to be advanced users who prefer to have the most current software.
There are other tools beside portsnap, of course. For example,
net/svnup is quite popular for fetching source and ports. Unlike portsnap, it supports branches, and there is no default. You have to specify the branch that you want. So you can use svnup to fetch a quarterly branch and build from it without problems. Of course, you can do the same with svn, svnlite or git if you want. The advantage of svnup is that it just fetches the files, without all of the overhead of local repository data, so the end result is exactly the same as if you used portsnap, except that you
can use branches.
For that reason I’m not afraid of portsnap going away, because svnup is a good replacement. And even if svnup didn’t exist (or stopped working for some reason), svnlite can be used as well. Since there’s a git-to-svn gateway, it’ll continue to work even when the FreeBSD repositories switch over to git. (However, I assume that there will be specialized tools for git at some point in the future, maybe an svnup-workalike called “gitup” or something like that.)
It's not about forbidding, but to help newbies to prevent to shoot themselves in their foot.
Well, as the saying goes:
“UNIX does not prevent you from doing stupid things, because that would also prevent you from doing clever things.”
But seriously … Well, yes, portmaster has some bugs and shortcomings. I think nobody is denying that. It is probably fair to say that it should not be the first choice for newbies. However, the OP of this thread doesn’t appear to be a newbie.
Note that it is a shell script of >1 kLoC
Uh … Are you sure? I assumed it was much larger. I have to admit I’ve never looked at it myself, only read about it at various occasions.
My own script is currently 2.2 kLoC, plus a few small helper scripts that add up to another 0.5 kLoC, roughly. (One third of that is comments, though.) Of course, it started as a much smaller script. If I had known at the beginning how it would evolve, I would have written it in Python instead, probably. But I’m not going to rewrite it now. It’s still manageable as a shell script since I made some efforts to have it structured in a useful way.
bsdconfig(8) and other (G)UI tools use
pkg(8) under the hood.
Yes, of course. Likewise, all of the various ports building tools use the ports collection’s Makefile framework under the hood.
Please note that some ports are self-contained in the
ports(7) tree (scripts) and do not exist as binary package; i.e. these can only be installed from
ports(7).
There are several reasons why no binary packages are provided for certain ports. For example, some software has license restrictions that prohibit binary redistribution, or you have to confirm a license agreement when you build the port. Also, some ports cripple their options when building a package for redistribution – for example, the binary package of
audio/sox has
no LAME support (for mp3 encoding), even though the LAME option is enabled by default when you build the port yourself. Furthermore, some ports must always be compiled from source because the package is specific to the local machine for some reason (e.g. it puts hardware-specific things in the binary, or a different key is generated each time you build the port, or similar). Currently there are about 250 ports affected by things like that.
On the genuine topic, my recommendations are […]
Agreed on all points. ?
