--On June 6, 2014 at 5:27:58 PM +1000 Dewayne Geraghty
<[email protected]> wrote:
On 6/06/2014 11:05 AM, Erich Dollansky wrote:
Hi,
On Thu, 05 Jun 2014 15:09:53 -0500
Paul Schmehl <[email protected]> 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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
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
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[email protected]"
