From owner-freebsd-hackers@FreeBSD.ORG  Fri May 23 13:08:03 2003
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 2EE9E37B401
	for <freebsd-hackers@FreeBSD.ORG>;
	Fri, 23 May 2003 13:08:03 -0700 (PDT)
Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net
	[66.166.149.50])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 8CCCC43F3F
	for <freebsd-hackers@FreeBSD.ORG>;
	Fri, 23 May 2003 13:08:02 -0700 (PDT)
	(envelope-from kientzle@acm.org)
Received: from acm.org (big.x.kientzle.com [66.166.149.54])
	by kientzle.com (8.12.9/8.12.9) with ESMTP id h4NK82tJ058263
	for <freebsd-hackers@FreeBSD.ORG>;
	Fri, 23 May 2003 13:08:02 -0700 (PDT)
	(envelope-from kientzle@acm.org)
Message-ID: <3ECE800F.9040104@acm.org>
Date: Fri, 23 May 2003 13:09:51 -0700
From: Tim Kientzle <kientzle@acm.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.6) Gecko/20011206
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: freebsd-hackers@FreeBSD.ORG
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: pkg_add and osreldate
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
Reply-To: kientzle@acm.org
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2003 20:08:03 -0000

pkg_add currently has logic to determine which dir
(under ftp://ftp.freebsd.org/pub/FreeBSD/ports)
to use for downloading packages.  This is driven
by the following table:

> { 410000, 410000, "/packages-4.1-release" },
> { 420000, 420000, "/packages-4.2-release" },
> { 430000, 430000, "/packages-4.3-release" },
> { 440000, 440000, "/packages-4.4-release" },
> { 450000, 450000, "/packages-4.5-release" },
> { 460000, 460001, "/packages-4.6-release" },
> { 460002, 460099, "/packages-4.6.2-release" },
> { 470000, 470099, "/packages-4.7-release" },
> { 300000, 399000, "/packages-3-stable" },
> { 400000, 499000, "/packages-4-stable" },
> { 510000, 599000, "/packages-5-stable" },
> { 0, 9999999, "/packages-current" },

This table is searched linearly; the first
entry where osreldate falls within the indicated
range is used.

Problem:  If someone runs this on a 4.5-STABLE
system, for instance (osreldate=450100), then
they will be directed to "packages-4-stable".
It seems that packages-4.5-release would
be more appropriate.  Similarly, this logic claims
that a 3.x system should be using packages from
5-stable!  (Though I don't consider that
a serious problem, of course. ;-)

I'm considering a simpler scheme: choose the
first item with version <= osreldate.

>   { 440000, "/packages-4.4-release" },
>   { 450000, "/packages-4.5-release" },
>   { 460000, "/packages-4.6-release" },
>   { 460002, "/packages-4.6.2-release" },
>   { 470000, "/packages-4.7-release" },
>   { 480000, "/packages-4.8-release" },
>   { 490000, "/packages-4-stable" },
>   { 500000, "/packages-5.0-release" },
>   { 510000, "/packages-5-current" },
>   { 520000, "/packages-5-current" },
>   { 600000, "/packages-current" },


This would seem to provide cleaner handling
of the various borderline cases.

Any thoughts?

Tim