Has the port collection become to large to handle.

[Panagiotis Astithas]

fbsd wrote:
> So people them use the packages. But the problem with the
> packages is they are not updated every time changes are
> made to the port they were created from. Also packages that
> have dependants like php4/php5 or mysql4/mysql5 are not being
> updated to use the newer versions of those dependants as they come
> out.

I believe that one solution to the scalability problem of creating and 
maintaining updated packages, would be to decentralize it more. Each 
time I submit an update for one of the ports I maintain, I've already 
build the relevant packages, as a QA measure. There should be no need to 
wait for the ports cluster to build the official version, instead of 
using my own, modulo perhaps the higher quality assurance you'd get from 
Kris's build infrastructure.

This is what you usually get in the Windows/Mac/Linux world. Macromedia, 
for instance, provides their own packages for Flash, naturally. The 
Eclipse foundation  provides binary packages for, say Linux, but Red Hat 
has chosen to provide its own rpm's from their repo.

What if we taught pkg_add to use something like INDEX, instead of a 
global PACKAGESITE variable, to hold information about each port's 
remote site? What if this was the secondary site, while the freebsd.org 
one remained the primary? This way you'd try to get the "official" 
package first and if you failed to find it, you'd get the maintainer's 
copy. Many people (myself included) have been doing something similar 
for GNOME and KDE, by asking portupgrade to try the marcuscom and 
fruitsalad repositories first.

Or how about we don't consume the cluster's capacity for building 
packages, but just for QA? Why not require me (the maintainer) to 
send-pr a URL to fetch the package's from and store them in the cluster 
(or straight to ftp-master)? Of course this would not work for people 
without the means to host the packages, or for unmaintained ports. We'd 
still have to use the ports cluster for them. For the security paranoid, 
add a big fat warning, that the contents of these packages are not 
verified or endorsed by the project. Maybe even, use two download 
locations: one for packages built by the cluster and another for 
packages submitted by the maintainers. IIUC, most Linux distributions 
have a similar arrangement.

Bottom line, since the package building role is becoming unbearable (at 
least for a timely delivery) for the project, why not let the ones who 
are already creating packages on their own, share the burden?

Regards,

Panagiotis

P.S.: it hasn't escaped me that using packages created from different 
systems could present dependency mismatches. But I would argue that this 
should be the maintainer's concern and moreover, it is something that is 
deemed acceptable in other systems. Furthermore, one could always use 
the ports system if he prefers.