Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 26 Apr 2006 23:23:31 +0300
From:      "Panagiotis Christias" <christias@gmail.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: Obsolete packages
Message-ID:  <e4b0ecef0604261323p32be28c6iea1f864cf8dc0083@mail.gmail.com>
In-Reply-To: <20060424234755.GA21411@xor.obsecurity.org>
References:  <20060424165021.GA1367@lena.kiev> <444D1BEF.5010704@computer.org> <20060424222727.GA20219@xor.obsecurity.org> <e4b0ecef0604241639q6d43029wa4845a1211fb85bf@mail.gmail.com> <20060424234755.GA21411@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On 4/25/06, Kris Kennaway <kris@obsecurity.org> wrote:
> On Tue, Apr 25, 2006 at 02:39:58AM +0300, Panagiotis Christias wrote:
> > On 4/25/06, Kris Kennaway <kris@obsecurity.org> wrote:
> > > On Mon, Apr 24, 2006 at 01:41:51PM -0500, Eric Schuele wrote:
> > > > Lena@lena.kiev.ua wrote:
> > > > >Hi,
> > > > >
> > > > >A new version of a port (www/firefox) was released on April 14.
> > > > >
> > > > ># portversion -v firefox
> > > > >firefox-1.5.0.1,1           <  needs updating (port has 1.5.0.2,1)
> > > > >
> > > > >But packages still (on April 24) are of previous version:
> > > > >
> > > > >$ ftp ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/i386/
> > > > >ftp> dir packages-5-stable/All/firefox-1*
> > > > >-rw-r--r--    1 110      0        11188636 Apr 01 16:29
> > > > >firefox-1.5.0.1_2,1.tbz
> > > > >ftp> dir packages-6-stable/All/firefox-1*
> > > > >-rw-r--r--    1 110      0        11511879 Apr 02 10:21
> > > > >firefox-1.5.0.1_2,1.tbz
> > > > >ftp> dir packages-7-current/All/firefox-1*
> > > > >-rw-r--r--    1 110      0        11511428 Apr 03 04:40
> > > > >firefox-1.5.0.1_2,1.tbz
> > > > >
> > > > >Is something broken or is there insufficient computing power for
> > > > >building new packages more often?
> > > >
> > > > It's my understanding that packages are built "when possible".  The=
y
> > > > often lag that which is in ports.  There are only so many cycles in=
 a
> > > > day (per cpu and per person).  I would assume that there is some lo=
gical
> > > > order in which the packages are built (most used first? Though not =
sure
> > > > how that would be determined)
> > >
> > > I continuously rebuild packages using a method that only builds
> > > "changed" packages (new, updated to new version or with a dependency
> > > that was changed).  This typically gives a turnaround time on i386 of
> > > less than a day to several days for packages becoming available, but
> > > as I said in another reply I'm not uploading them now because of the
> > > looming release cycle.
> >
> > With no intention to criticize your way of thinking or your work,
> > release cycles sometimes could take a bit more time than scheduled.
> > You, the developers and maintainers, know that better than us, the
> > users. In the mean time there is a whole community of (end?) users
> > that could benefit from the prompt availability of latest ports in
> > packages. I'm referring mostly to desktop or workstation users, since
> > the most of us build our ports from the sources for our servers.
> > Although, I'm eager to use the "portupgrade -P" option more often for
> > our (less critical) ports.
> >
> > Is there a chance that you, along with the release engineering team,
> > reconsider your policy?
>
> It's basically forced upon us by the finite bandwidth of mirror sites.
> At release time they have many gigabytes of ISO images and other
> install media, etc to download, without adding many gigabytes of
> packages.  If we don't back off from uploading packages in the lead up
> to the release, then what happens is that many mirror sites are out of
> date and do not carry the release media at the time of release.

Well, speaking as the maintainer of the ftp.gr.freebsd.org mirror site
I would say that in this case the monolithic form of the FreeBSD FTP
repository is a drawback. Mirroring around 350GB/1.600.000 files, or
even a subset, is a difficult (see insufficient) task. Separating the
repository and the mirroring process in parts (releases, packages
etc.) could be a solution..

Regards,
Panagiotis



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e4b0ecef0604261323p32be28c6iea1f864cf8dc0083>