Has the port collection become to large to handle.
fbsd
fbsd at a1poweruser.com
Sun May 14 13:04:10 UTC 2006
Comments have been posted about how to determine in a fair way
which ports would be included in the most commonly used category?
The solution to that concern is pretty easy to do.
Modify the master make code to post a count to a special
purpose FreeBSD website by passing it a cookie.
Now every time a any user runs the port "make install" that
special purpose FreeBSD website will be accessed counting
how many times that port is really executed. Then use that
count per new release of FreeBSD to determine the ports that
go into the commonly used category. The side benefit is this
would also bring to light the dead and unused ports that can
be removed from the ports collections or put in an unsupported
category which would further help in controlling the size of
the base collection. Of course some precautions in counting the
hits to the special purpose FreeBSD website would have to be used
to drop attempts by people trying to manipulate the results in
favor of some particular port.
The comments from one of the maintainers about the fact that
the maintainers are not allowed to build the official
packages is a policy that can easily be changed.
Its more important to have timely packages available then
the security of waiting for the mass package build done once
per new FreeBSD version release. A warning comment in the
maintainer built package informing the installer that this
package was built by the maintainer and not by the secure
mass package build process will give the installer the info
he needs to decide if they want to use that version of the
package or wait for the official secure built version.
This also allows the maintainer to build different versions
of the package for each different version of major dependents
such as php4/5 apache1/2 mysql3/4/5 whatever.
The mass package build process does not allow this flexibility.
The fact is the maintainer is all ready being trusted to
manage the port so I see no reason NOT to trust him to
create the matching package.
Even the need of the secure massive package built process is
now questionable.
The resources and time needed for performing the
secure massive package built must impact the release timeline of
new FreeBSD releases. Doing away with it may streamline many
other different internal release process.
More information about the freebsd-ports
mailing list