Date: Wed, 03 Dec 2008 16:27:00 -0500 From: Sean McAfee <smcafee@collaborativefusion.com> To: Peter Schuller <peter.schuller@infidyne.com>, freebsd-ports@freebsd.org Subject: Re: Deterministic package building with ports Message-ID: <4936F9A4.8030504@collaborativefusion.com> In-Reply-To: <20081203211627.GA56450@hyperion.scode.org> References: <20081203210233.GA55633@hyperion.scode.org> <20081203211627.GA56450@hyperion.scode.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Schuller wrote:
>> consistently. tinderbox I presume works, being used for official bulk
>
> Scratch the bit about tindexbox; brain lapse.
>
> But I also wanted to clarify that I specifically do not want to
> perform in-place upgrading from source, because the intent is to have
> a minimal time window during which the system is inoperative. In fact
> the current procedure is do pkg_delete *all* packages and just
> re-install. This is in fact fine (though it would be better to be able
> to intelligently re-install only what is needed).
>
> However note that I specifically do *not* want to play games with
> trying to minimalistically upgrade only those things that specifically
> are required according to dependency information. I gave up on this
> years ago; it just doesn't work without some perfect mythological
> ports tree. I specifically want to build packages from a snapshot of
> the ports tree; I do not want to mix old/new software, regardless of
> whether the dependency claims that some particular major version of a
> library is supposed to be compatible. The intent is to effectively
> build and deploy something which is as close as possible to what the
> port maintainer/build cluster will have tested, at all times.
>
I do something similar on a limited basis for clustered servers. It's a
bit different because they all (theoretically) have the same packages
installed, but I use this procedure:
On the "donor" system:
1. portupgrade -a
2. for a in `pkg_info -ao | awk '{ print $1 }'` ; do pkg_create -b $a ; done
3. Push packages up to NFS'ed ports tree host's /usr/ports/packages
On the remaining systems, it's just a matter of running portupgrade -aPP.
Some pros:
1. Any local modifications (like to the rc script) follow the package
2. Easy, easy, easy
3. No "already installed" errors from doing make package
4. Automatically builds dependent packages
Some cons:
1. Assumes that there are similar packages on all systems - i.e. no xorg
2. If the package is unavailable, it'll try to fetch it. This isn't a
problem for us because firewall rules prevent the machines from getting
to the internet, but it could be for others.
As long as you'd be able to "profile" your varying systems (web servers
vs. db servers vs. whatever) in jails, something similar might work for you.
--
Sean McAfee
System Engineer
Collaborative Fusion, Inc.
smcafee@collaborativefusion.com
412-422-3463 x 4025
5849 Forbes Avenue
Pittsburgh, PA 15217
****************************************************************
IMPORTANT: This message contains confidential information
and is intended only for the individual named. If the reader of
this message is not an intended recipient (or the individual
responsible for the delivery of this message to an intended
recipient), please be advised that any re-use, dissemination,
distribution or copying of this message is prohibited. Please
notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission.
****************************************************************
IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4936F9A4.8030504>