freebsd 5.3-release and some observations

[jason andrade]

On Wed, 17 Nov 2004, Kris Kennaway wrote:

>> given the length of time for package tree updates i'd be
>> asking if there is any thoughts that could be raised about
>> how better to supply package trees so they aren't `tied'
>> to an architecture and thus appear to be released in 3-5G
>> chunks.
>
> package trees are absolutely tied to an architecture, because they
> contain compiled files that will only run on that architecture (modulo
> things like amd64-i386 compatibility).

sigh, i should have been more precise, what i meant was $ARCH/$VERSION.

for example, is it possible to `compress' packages within architectures if 
there's no problems with running 5.2.1 packages on 5.2 - does that hold for
5.2 packages on 5.3 or 5.1 ? you'd then end up with a package tree of
say FreeBSD5 with only minor version specific releases.

i'm only throwing this up as a future suggestion - i can understand if
the package build methodology and QA means that it's easier to stick
with the current system that works..

> a bit less frequently because the builds take longer.  Note that 4.x
> and 5.x builds are usually incremental builds thesedays, meaning that
> if the package doesn't change it isn't changed on the server, thus
> reducing mirror download bulk.

that's pretty cool.  i should start doing some stats to measure the
actual rate of change in the archive.  thanks ken, more work :-)

>> should mirrors carry this ?
>
> If at all possible, yes.  Mirrors are most useful when they're
> complete mirrors.

nod, i'm just balancing that against updating (relatively) large data
sets that may not get used that much and/or it takes a while to update.

in particular as the number of architectures grow then mirroring every
-current package tree could result in quite a large update to all
mirrors without a corresponding benefit - say 6 archs by 3G each is
18G/week in updates.


regards,

-jason