pkg_add for 5.2.1 no longer working...

[Darryl L. Miles]

Thanks for all your replies.  I'm understanding the FreeBSD picture at 
lot better now.


My situation is that my ISP pre-installed quite a number of boxes with 
5.2.1 on my behalf, thinking they would have better knowledge of FreeBSD 
to do the right thing for me.  This is my first encounter with FreeBSD 
in a production environment I've had no problems setting up the original 
box and no idea that version of OS I was using was a "new technology 
release".  If it comes down to having to reinstall all the boxes (at my 
cost) unfortunatly FreeBSD wont be the first choice to put back on them, 
since the application doesn't care and my experience if far greater with 
other flavours of unix.

One thing I have noted with FreeBSD is that the ports generally go into 
/usr/local, I find it easy to administer multiple systems across the 
globe if the base OS and distribution is installed, plus any standard 
vendor supplied packages, then any manually compiled system packages be 
installed into /usr/local and any machine specific applications be 
installed into /opt.  Machine specific taken to mean this boxes job in 
the world is to be a DNS server, so I have bind build and running in 
/opt and the vendor supplied one not installed or disabled.  This way I 
can still install all of the vendor security updates without it 
conflicting with anything else and without it upsetting the boxes job in 
the world.

I notice from current discussion that perl (for example) is now a port 
and being moved into /usr/local, what I regard as vendor supplied 
packages do not belong in /usr/local but in the main tree.  Vendor 
supplier 'ls' and vendor supplied 'perl' should be together.  
Administrator personally built tool should go into /usr/local.  I 
completely understand perl being an add-in component, I fully support 
the "perl is optional" part of the initiative.

Yes I do want two versions of some utils, since I do not wish my 
updated/upgraded version to affect all the vendors supplier system 
parts.  The reason why I upgraded it was to allow me to use a new 
feature for my application, so my application is configured to use my 
updated version.  While the vendors part of the system has been well 
tested using his version of the same utility as /usr/local/bin is not 
the default path.

If I now have "vendor supplied tools" conflicting with "Admin personally 
built tools" then I loose all the benifits of using vendor supplied 
binary packages I partially outlined in my previous email.  That is the 
system as a whole in all its complexity benifits from being testing by a 
far greater audience than I alone so I wish to keep that part as stable 
as possible, while I turn my own attention to what that boxes job in the 
world actually is.


>>>Free BSD's policy seems to read that once a new mainline release comes 
>>>out, users now have to start building their own binary ports for their 
>>>old version of Free BSD.
>>>      
>>>
>
>That's only true for cases where a new -STABLE branch is created, such
>as happened with 5.3, where all packages had to be rebuilt because the
>shared library bumps happened just before 5.3-RELEASE.  We've learned
>from that lesson, as well, and intend to do the bumps much, much,
>earlier in each major release cycle.
>  
>
Yes I understand that all the packages for 5.3 have to be rebuilt, but 
this does not have any bearing on the availability of the already 
existing packages for the previous release, I'm saying they should be 
frozen and marked up as superceeded (by some never package version).  
That never version has a dependacy on 5.3-RELEASE being installed.  Then 
everyone can be happy ?

>But the key is your use of 'mainline release': 5.2.1 was never intended
>to be a 'mainline release', it was always a 'technology preview'.  The
>previous 'mainline release' is really 4.11 and it still has packages
>available for it and will continue to in the medium-term.
>  
>
First impressions of the uname -a output with the word "-RELEASE" give 
me the impression something has been cast into stone (for a while at 
least).  Cisco routers used to use the kind of release types you're 
using, like Engineering Release / Maintainence Release and this would 
head all announcement, release notes and PR info when discussing that 
specific version.  Maybe -PREVIEW or -RELEASECANDIDATE or -UNSTABLE or 
-ALPHA would be clearer to people like me.


Darryl