Who was the mental genius

[Paul Schmehl]

--On June 6, 2014 at 5:27:58 PM +1000 Dewayne Geraghty 
<dewayne.geraghty at heuristicsystems.com.au> wrote:

> On 6/06/2014 11:05 AM, Erich Dollansky wrote:
>> Hi,
>>
>> On Thu, 05 Jun 2014 15:09:53 -0500
>> Paul Schmehl <pschmehl_lists at tx.rr.com> wrote:
>>
>>> That decided it was a good idea to completely break ports to force
>>> people to upgrade?  You couldn't come up with a warning system
>>> instead of outright breaking ports?  The idiots are apparently
>>> running the asylum.  {{sigh}}
>>>
>> this is the reason why I am asking for versions on the ports tree since
>> a decade. Ok, we have the revision now. Just go back in the revision
>> until it works. It is a good practice to make a note of the revision of
>> the running ports tree you have before updating it.
>>
>> Erich
>> _______________________________________________
>> freebsd-ports at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
>> To unsubscribe, send any mail to "freebsd-ports-unsubscribe at freebsd.org"
>>
>>
> Paul,
> I would echo Enrich's advise.  Occassionally over the last 18 months my
> ports tree build (of 487 ports) would fail.  A workaround, for me, was
> to update the ports tree and then revert /usr/ports/Mk - sometimes I'd
> search through the svn logs for a clue, but more recently I'd revert a
> week at a time.  This being done to get something urgent out of the way
> until a PR or fix was acted upon, and the folks supporting ports
> meta-system are extremely responsive.  Of course if a port needs
> something that was changed under /usr/ports/Mk then you'll probably have
> to revert the port as well and change the VERSION info as needed - this
> is time-consuming and you really need to set aside some time for
> testing.  Its a real kludge but if you're stuck...
>
> As I recall the change to ports to use a different make was tied to EOL
> for 8.3, seems reasonable though something of a paradigm shift for ol'
> timers (I'm a 2.2.5 person) that are used to building ports on a system
> long after the base system has been EOL.
>
> However it does lend itself to the argument that if changes to the ports
> system is tied to the base operating system, then the meta-ports ie
> /usr/ports/Mk should also.  Unfortunately release management of the
> ports meta-system, after a decade, remains elusive.  Though it should be
> noted that preparatory communication is improving - thanks to the team
> and Eitan's contributions.
>
> During some side-conversations I was surprised to learn that there is
> some back-porting of fixes taking place in the ports branches ref:
>
> http://svnweb.freebsd.org/ports/branches/2014Q2/  (thanks to Guido for
> bringing that to our attention). So maybe this is your starting point and
> svn update the particular ports you require is another option (as a
> temporary workaround)?
>

I appreciate the advice.  I've elected to setup an alternate form of backup 
(using rsync over ssh to backup each server to its sibling) so I can 
upgrade to 8.4 without worrying about a loss.  Once that's complete, I'll 
get the new backup system in place (using Storgrid backing up to a SAN at 
the hosting provider).

After that I can comfortably move to 9 or 10.  I don't like running 
"bleeding edge" releases on production servers.  This work I'm doing is 
entirely voluntary, for a hobby website with a small budget, so I have to 
be very careful about not breaking anything.

When I installed one of these servers 9 wouldn't even install (missing RAID 
drivers), which is why I used 8.

-- 
Paul Schmehl, Senior Infosec Analyst
As if it wasn't already obvious, my opinions
are my own and not those of my employer.
*******************************************
"It is as useless to argue with those who have
renounced the use of reason as to administer
medication to the dead." Thomas Jefferson
"There are some ideas so wrong that only a very
intelligent person could believe in them." George Orwell