Regenerate ports tree from installed ports?

[Mike Meyer]

On Thu, 25 Sep 2008 23:25:46 +0200
Jordi Espasa Clofent <jespasac at minibofh.org> wrote:

> Hi all,
> 
> I suppose it's a dumb (and crazy) question, but as post subject says:
> ¿Is it possible to regenerate the /usr/ports tree _from_ the installed 
> ports?

Possibly. If the installed ports were built from a consistent tree,
you can always just use CVS to check out a copy of the ports tree for
the date of the last port you installed. However, as was pointed out
here, that doesn't mean you can actually build ports from them on an
upgraded operating system.

> Until that point, it's all right. But everybody knows that you have to 
> recompile all your installed ports after the kernel and userland 
> upgrade, to re-link the new libraries and disappeared ones.

Um, no, everyone doesn't know you need to do that. In fact, I've
almost *never* been able to do that, because I've almost always had
proprietary, binary-only software of some sort or another running on
my boxes for which the vendor hadn't provided an appropriate
update. That's what the compat libraries are for - you can install
those, and just keep on running your old binaries. It's been a while,
but I'm pretty sure I managed one update by doing the OS update -
including compat - and then replacing the ports piecemeal while the
old ones ran on the compat libraries.

Of course, running on the compat libraries isn't the ideal solution,
so you want to rebuild the ports if you can. Of course, the same thing
applies to running old versions of the ports - you really want to get
new bug fixes, security patches, and such like that may have come out
since you installed the original software. 

> But in my 
> case, these boxes are used as shared web-hostings, and a lot of 
> particularities are present. Change the php version, for example, can 
> means that tens of webs not work fine.

The solution in this case is to buy one new box, build the new version
on it, including all ports, clone your customers environments to it,
and start it as "foobar-new". Tell your customers it's there, let them
test things, help them fix what's needed, and after everyone is happy,
swap the names. Repeat this process using the just-retired box to
build the new one on.

If these are inhouse services - so you can have some real down time -
then I typically build a new system on a second disk with the same
data directories, and test there. When it's all working, put
everything on one disk, and then mirror the two disks, so it's there
next time I need to do the dual boot upgrade thing.

     <mike
-- 
Mike Meyer <mwm at mired.org>		http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org