Has the port collection become to large to handle.

[Joseph Kerian]

On 5/13/06, Frank Laszlo <laszlof at vonostingroup.com> wrote:

> > We could also use this info to prune ports not getting
> > any use at all.
> Then when someone does need it, it wont be there, and will have to be
> re-ported.
> >
> > In addition to that a method of syncing ports indivitually
> > might be an alternative way to go. That way instead of
> > syncing the many thousands of ports to compile up the
> > latest version of XXX you would only have to download
> > the port you wanted and any dependencies.
>
> This is a neat idea that Marc brought up. Perhaps a dynamic ports tree
> is the answer. With an up to date INDEX, It probably wouldn't be hard to
> patch the ports system to download JUST the ports you need, and their
> dependencies. We would just have to decide on the method to do this. I
> suppose something like cvsup, or portsnap could be utilized to checkout
> single ports. But then again, after that, whats the point of even having
> sub directories for ports? Why not just have it download the framework,
> build the port, and delete everything. Now its starting to resemble
> debians apt-get. *shrug*


The resemblance is not, in and of itself, a bad thing. Is there anything
preventing someone from making a portupgrade-like tool that uses only tmp, a
/ports dir on an ftp site and a bit of intelligence regarding dependency
resolution? Correct me if I'm wrong, but I'm not seeing any technical
reasons this couldn't be done. (okay... so your equivelent of portversion
might get a little more complicated or potentially wierd)
I would submit, however, that it hasn't been done simply because it isn't
needed. 210 mb is laughably insignificant on any system I would build ports.
Although you can say that the number of ports is increasing, disk size is
doing the same; I'm unconvinced that the ports tree size is growing fast
enough to outpace either the expansion of high speed networks or modern
disks. This may change of course, but we would likely have some warning. :)

Regards,
Joe Kerian