Re: HOWTO articles for migrating from Linux to FreeBSD, especially for pkg?

On 21 Oct 2014, at 00:15, Mason Loring Bliss <mason_at_blisses.org> wrote:

> The second thing that would be useful would be a series of cheat sheets for
> various things. This can either be equivalent commands or equivalent systems.
> Let new folks know that LUKS is GELI and that md-raid1 is gmirror and so
> forth. Show common package handling commands for various Linux flavours and
> map them to pkgng and ports. For instance, what's the equivalent of "yum
> provides"? Or what do I do in place of "apt-cache search" or "zypper up" or
> similar.

I agree that this would be useful, but it requires someone familiar with both systems to write.  Perhaps you could help by coming up with a list of things that you did frequently with Debian and a description of what they did, then someone more familiar with the FreeBSD side can help fill in any gaps where you haven't yet worked out what the FreeBSD equivalent is (or, if there isn't a FreeBSD equivalent, then we have a useful feature request).

> Other things in the grab bag... It's generally said that ports and pkgs
> shouldn't mix, but there are at least a couple instances where it's
> unavoidable:
> 
> I bet roughly no one who installs Subversion wants the FreeBSD bug report
> headers baked in by default, but there they are unless you rebuild from ports
> with a non-default configuration.

It's worth noting that the FreeBSD headers don't affect operation.  Subversion only adds the headers to the commit message if they're modified.  I think that the fix for this is to add a line at the top saying

# Things below this line are only included if modified

I find that I do occasionally use those in other projects.

> If you want to watch DVDs on your FreeBSD workstation, it's necessary to
> install libdvdcss, but you can't get it from pkgng because it's not there.
> Again, you must build from ports.

Really?  I've installed vlc from packages and it seems able to play DVDs.  I don't remember having to do anything special.  Perhaps I had an old version of libdecss installed.  I thought that CSS had been ruled not to be an 'effective copyright protection mechanism' in the US, so wasn't covered by the DMCA anymore.

> I have nothing against ports, but people are warned off of mixing packages
> and ports when clearly it's necessary sometimes.
> 
> Oh, here's one. I *was* horrified by ports at first, until someone told me
> about "make config-recursive". It really makes me wonder why this isn't the
> default. I remember giving up on FreeBSD when 9.x was new because I had to
> build X from ports after the FreeBSD breach, and it seemed like the process
> was going to take a couple days of stuttering stops and starts as random
> packages I didn't want in some cases popped up between compiles. I learned
> some mechanism for saying "just take the defaults" but what I know now is
> that what I really wanted was "make config-recursive". Why, out of curiosity,
> is it not the default? That would seem better than documenting it harder.

The recommended way of building packages now is to use Poudriere.  The Poudriere section in the handbook is still very new and contributions are *very* welcome.  I think that having an example of 'how to build libdecss from ports' there might be a good idea.

There is a plan that each package set should come with a package containing the matching ports tree, so that you can build package from ports that are compatible with the binary ones.  That should make a lot of this easier.

I think the two cases for Poudriere that need to be in the handbook are:

- How to build a few custom packages but mostly use upstream for an individual

- How to build a local package repository for your organisation with a load of custom config options for packages built from ports and some custom local-only ports

> Ah, and one more for the grab bag. I strongly suspect that many folks coming
> from Linux are going to bristle at the notion of using Sendmail. I used to
> run it so I wasn't terribly bothered by it, but maybe pre-populating rc.conf
> with obvious bits that people can see and turn off would be nice. OpenBSD has
> a nice model of populating rc.conf and sysctl.conf fully, and it ends up
> being a pleasant tool. Those awash in wonder, coming from Linux, can say,
> "Look, it's all right here!"

We put those things in /etc/defaults/rc.conf, which makes merges easier on upgrade: the user doesn't touch /etc/defaults/rc.conf and the update tool doesn't touch /etc/rc.conf.  Again, if the handbook doesn't tell you to look in /etc/defaults/rc.conf then that's an oversight that we should fix.

It might be a good idea to move this thread to the -docs mailing list, as it seems to have identified a number of shortcomings in our documentation and it would be a good idea to try to find some docs people willing to help get them fixed.

David