From owner-freebsd-ports@FreeBSD.ORG Tue Feb 22 06:44:31 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 4C07916A4CE for ; Tue, 22 Feb 2005 06:44:31 +0000 (GMT) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9FB143D5A for ; Tue, 22 Feb 2005 06:44:30 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 77A4014959; Tue, 22 Feb 2005 00:44:30 -0600 (CST) Date: Tue, 22 Feb 2005 00:44:30 -0600 (CST) From: Mark Linimon X-X-Sender: linimon@pancho To: "Darryl L. Miles" In-Reply-To: <421960BE.3050105@netbauds.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: ports@freebsd.org 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: Tue, 22 Feb 2005 06:44:31 -0000 On Mon, 21 Feb 2005, Darryl L. Miles wrote: > 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. Unfortunately I think it is the case that for someone without an in-depth knowledge of the FreeBSD development process, they should have installed 4.10 or 4.11 for you. > If it comes down to having to reinstall all the boxes (at my cost) > unfortunately FreeBSD won't be the first choice to put back on them, > since the application doesn't care and my experience if far greater > other flavours of unix. One of your options is to try the 'binary upgrade' which one of our volunteers maintains (URL, anyone?) But this may be a more advanced topic than someone not as familiar with FreeBSD could tackle. > 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. Unfortunately for your case, this is not the approach that FreeBSD has taken. The approach is that the base system should be as lean as possible. The problem with having perl in the base system is that it was always some number of versions behind and too many things started to depend on particular versions. Everything became fragile. > If I now have "vendor supplied tools" conflicting with "Admin personally > built tools" then I lose all the benefits of using vendor supplied > binary packages I partially outlined in my previous email. The reason FreeBSD has taken the approach it has is try to get a maximum degree of testing coverage for ports such as lang/perl so as to try to make it as well-integrated as possible. With the framework we have, and the number of volunteers that we have, any other approach just isn't feasible. You had also mentioned trying to keep a set of 5.2.1 packages available and 'frozen'. It's not feasible to do that; the FreeBSD ports tree is not branched; therefore, keeping up to date on any port means that you need to track the entire ports collection. With that, the names of the binary packages will change as each port is upgraded. With weeks you'd be left with the same situation that you're in right now. > 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). There is still some debate about whether our next development-to-stable transition ought to be 6.0-RELEASE or some prerelease type of name. Please note that we do, indeed, do prereleases as well. But the problem is that you are asking for a level of support from a volunteer project that it simply isn't possible to give to every possible combination of requirements. As already stated, the lessons learned from the 5.2.1->5.3 transition have been learned, and we've completely changed the way that we are going to do releases in the future based upon it. We are currently supporting both 4-STABLE, 5-STABLE, and 6-CURRENT (the newest development branch) simultaneously. This is as much as we can do; we really lack the resources (and frankly, inclination) to go back and support anything other than those. We are fast approaching the release cycle for 5.4 and going backwards is just simply not in the cards. Beyond all this, I just don't see what further we can do as a volunteer project. I think that the only choice for a lot of the issues you're looking at in terms of wanting to have multiple versions of ports available while upgrading to 5.3 is to investigate a commercial support contract. That's about the best advice that I can give. mcl