[Phishing]Re: Migrating to FreeBSD from Debian

[Andrew Berg]

On 2015.12.07 09:54, Daniel Feenberg wrote:
> 
> 
> On Mon, 7 Dec 2015, Lowell Gilbert wrote:
> 
>>> But we should warn then about not mixing ports & packages. I agree,
>>> pkg is a good choice [when pkg only].
>>
>> That's gradually become a much smaller issue than it used to be.
> 
> What does the warning mean? That once I have installed a single package I 
> can never use ports? So if I want a port, and already have packages, I 
> have to uninstall all of the packages first and can never in the future 
> install any package? That seems extreme. Or is there a less restrictive 
> interpretation that is more correct?
It has to do with mixing trees. Everything is packages, and packages come from
ports. If you get packages from the official repo, and then download the ports
tree and build and install your own, some packages won't play nice with each
other because they aren't from the same point in time (your copy of the tree is
a little bit newer than the one used by the official repo at the time). pkg
will detect most issues, but it can't generally fix them. It is possible to be
in sync with the official repo, but doing so is more complicated and requires
more hands-on attention. Trying to use the official repo and then mix in a few
of your own here and there is almost always more effort and trouble than it's
worth.
Ultimately, you have 3 options:
1. Use the official repo. This is the simplest and easiest. You never have to
compile anything or know how ports works and upgrades are easy. This also
scales to many machines easily. The downside is that you have limited
flexibility - no custom options and you can't change the default versions for
things such as Python, Perl, PHP, Apache, et al.. You also don't get updates as
soon as they're committed, but the time between updates is only about a few days.
2. Use ports tools directly (or a wrapper such as Portmaster) and compile
packages yourself. This is a little more work, but you get custom options for
your packages (and you can have your own custom modifications to the ports
tree). You can have new versions of packages within minutes of the changes
being committed to the tree (depending on how long it takes to compile).
However, you will have to compile everything and sharing these packages is
crude and possibly a bit error-prone because your environment is not 100%
clean. This doesn't scale well unless you build your own tooling to make it so.
Otherwise, you will have to compile everything you want on each individual
machine, and you will have to do some scripting to make your custom options
consistent across them.
3. Use Poudriere. This is essentially tooling to make #2 scale well. Once you
have packages built, it creates a repo, making them very easy to share. On your
other machines, you point them to your own repo instead of the official one.
They will all have the custom options and modifications you want, but you
compile once on one machine. Poudriere builds every package in a clean
environment using jails to help keep things consistent and less complicated
when there are issues.

I recommend #1 unless you have a compelling reason not to ("oh no, 100MB of
disk space is used up by a package I don't use" isn't one). If you really need
custom options (because you need something to get work done), then I recommend
#3. In any case, pick one and do that. If you want to switch from one approach
to another, reinstall all packages using the new approach.

As Matthew alluded to, things are being worked on to make options 2 and 3 less
necessary for most people, but there is still much work to be done in ports and
in pkg, and it will take a while to get it all done right.