Date: Mon, 9 Jan 2012 11:47:09 -0800 From: Devin Teske <devin.teske@fisglobal.com> To: "'Alejandro Imass'" <ait@p2ee.org> Cc: 'alexus' <alexus@gmail.com>, freebsd-questions@freebsd.org Subject: RE: ports vs packages Message-ID: <083a01cccf07$79fd35e0$6df7a1a0$@fisglobal.com> In-Reply-To: <CAHieY7RL5wf=Tk7-9KafudTFYbTHtXh9Ap9rDyVCM=5qEFN4ew@mail.gmail.com> References: <CAJxePN%2BWrr6K83RGFGERzJGUXc24i95BemPOgxqAJW_2Lsfjpg@mail.gmail.com> <07e401cccefb$364338b0$a2c9aa10$@fisglobal.com> <CAHieY7RL5wf=Tk7-9KafudTFYbTHtXh9Ap9rDyVCM=5qEFN4ew@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: aimass@yabarana.com [mailto:aimass@yabarana.com] On Behalf Of > Alejandro Imass > Sent: Monday, January 09, 2012 11:37 AM > To: Devin Teske > Cc: alexus; freebsd-questions@freebsd.org > Subject: Re: ports vs packages > > On Mon, Jan 9, 2012 at 1:19 PM, Devin Teske <devin.teske@fisglobal.com> > wrote: > >> -----Original Message----- > >> From: owner-freebsd-questions@freebsd.org [mailto:owner-freebsd- > > [...] > > > Of course, this is explicit to rather serious production environments. Desktop > 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 depends > 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). -- Devin _____________ 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?083a01cccf07$79fd35e0$6df7a1a0$>