Upgrading 5.3 > 6.0 buildworld failure now in libmagic

secmgr security at jim-liesl.org
Wed Dec 7 13:35:51 PST 2005


Doug Barton wrote:

> How does this change to UPDATING in RELENG_6 look to you:
>
> Index: UPDATING
> ===================================================================
> RCS file: /home/ncvs/src/UPDATING,v
> retrieving revision 1.416.2.7
> diff -u -r1.416.2.7 UPDATING
> --- UPDATING    1 Nov 2005 23:44:40 -0000       1.416.2.7
> +++ UPDATING    7 Dec 2005 00:42:04 -0000
> @@ -229,7 +229,13 @@
>         page for more details.
>
>         Due to several updates to the build infrastructure, source
> -       upgrades from versions prior to 5.3 no longer supported.
> +       upgrades from versions prior to 5.4-STABLE are not likely
> +       to succeed.
> +
> +       When upgrading from one major version to another, it is
> +       generally best to upgrade to the latest code in the branch
> +       currently installed first, then do another upgrade to the
> +       new branch.
>
Or as another poster said, just say latest RELENG_5 prior to upgrade

> This is an open source project. The only way that things improve is if 
> people help make it better. It's also worth pointing out that this 
> issue of upgrading to the latest version of the branch you're in has 
> been "common knowledge" for, basically, always; so if the folks that 
> wrote the release notes neglected to include it, it's understandable. 
> (Although, as you point out, potentially frustrating for new(er) users.)

Well, if it's common knowledge, lets see it documented.  We're only 
talking a few lines in the handbook or the release notes, not an entire 
chapter.

>> If RE wants to change the requirements for upgrading, then how 
>> bleeping hard would it be to update either release notes or errata.  
>> It's not so much that I now need to do multiple upgrades (ok, that IS 
>> pretty annoying), it's that I'd never of known unless I followed this 
>> thread.
>
>
> Ok, so, after you calm down a bit, why don't you write a message to 
> re at freebsd.org and mention this issue.

<rant3>
My frustration comes from the fact that this seems to be getting worse, 
not better.  In addition, every time I bring this up, I'm told (usually 
by someone with a freebsd.org address) that, "oh we all know/knew about 
that"  or, "it's common knowledge". In the case of the 
vinum/gvinum/gmirror trainwreck, I got silence, even though I strongly 
suspect multiple people knew there were problems, but just didn't want 
to talk about them.  I'd gladly help document some of this, but I'm not 
the one who knows where the skeletons are snoozing (at least till I trip 
on a femur)

So whats the big issue with letting the rest of us in on the secrets?  
I'm not looking for a book, just a line or two saying "here be dragons" 
somewhere /other /than the basement of the planing department in the 
bottom of a locked filing cabinet stuck in a disused lavatory with a 
sign on the door saying 'Beware of the Leopard' (apologies to Doug Adams).
</rant>



More information about the freebsd-stable mailing list