From owner-freebsd-ports@FreeBSD.ORG Mon Feb 21 04:17:13 2005 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7049D16A4CE for ; Mon, 21 Feb 2005 04:17:13 +0000 (GMT) Received: from mail-3.netbauds.net (mail-3.netbauds.net [217.158.188.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id B43BB43D2D for ; Mon, 21 Feb 2005 04:17:12 +0000 (GMT) (envelope-from darryl@netbauds.net) Received: from host81-133-225-66.in-addr.btopenworld.com ([81.133.225.66]:15744"DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail-3.netbauds.net with ESMTPSA id S50234AbVBUERL (ORCPT ); Mon, 21 Feb 2005 04:17:11 +0000 Message-ID: <421960BE.3050105@netbauds.net> Date: Mon, 21 Feb 2005 04:17:02 +0000 From: "Darryl L. Miles" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8a4) Gecko/20040927 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: ports@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: pkg_add for 5.2.1 no longer working... X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2005 04:17:13 -0000 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