ports vs packages

Devin Teske devin.teske at fisglobal.com
Mon Jan 9 19:47:09 UTC 2012

> -----Original Message-----
> From: aimass at yabarana.com [mailto:aimass at yabarana.com] On Behalf Of
> Alejandro Imass
> Sent: Monday, January 09, 2012 11:37 AM
> To: Devin Teske
> Cc: alexus; freebsd-questions at freebsd.org
> Subject: Re: ports vs packages
> On Mon, Jan 9, 2012 at 1:19 PM, Devin Teske <devin.teske at fisglobal.com>
> wrote:
> >> -----Original Message-----
> >> From: owner-freebsd-questions at freebsd.org [mailto:owner-freebsd-
> [...]
> > Of course, this is explicit to rather serious production environments.
> and casual usage ... ports may serve you better if you like to stay up-to-date
> rather than only upgrading once every 1-2 years.
> We think the opposite. Serious production environments should use specifically
> compiled ports for your needs and create packages from those. In fact we
> combine this approach with the use of EzJail and flavours. So I guess it all
> on the needs and what a serious production environment means for each
> company or individual.

Thanks for the nod ... indeed it varies from each company and individual.

Another thing to watch out for with ports is architecture-dependent
optimizations. Usually it's pretty safe so-long-as you don't heavily pollute
your make.conf or heavily dip-into the various config options for each port.

In our case, the concern is that if you optimize and then deliver to older
hardware, something goes awry.

You can often mitigate such things by using the "lowest common denominator"
amongst your clients hardware pool, and/or mandating a minimum-set of base
requirements that you target. Stating these requirements explicitly to your
customer base in a prominent section of the release-notes for each release
should assuage such problems, but it's also very important to get that list
(especially if there are big changes in the requirements from one release to the
next) to your customers in a timely manner *before* the actual release, so that
they can inventory their hardware pool (determining the "damage" if you will and
perhaps giving them time to perform a "tech refresh" to get up to speed with the
[potentially] new requirements).

Above all else, it's also paramount that (if you use ports heavily to compile
binary packages from which machines are subsequently built) should you ever
change out your compilation hardware, that you notify your customers of the
specs of your new build machine (considering that your build machine should
usually be representative of the lowest-common-denominator within the scope of
production hardware still in-use).

The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.

More information about the freebsd-questions mailing list