Has the port collection become to large to handle.
past at ebs.gr
Sun May 14 11:05:26 UTC 2006
> 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
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?
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.
More information about the freebsd-ports