Has the port collection become to large to handle.

[Ulrich Spoerlein]

fbsd wrote:
> 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.

I always thought of such a scheme too. Like the afterboot-manpage (IIRC)
on OpenBSD, where people are encouraged to mail their dmesg output to
the developers.

> 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. 

Hell no. Putting the burden on maintainers to build packages for various
architectures and releases is completely utopical. Not to mention the
fact, that they would have to build them in sandboxes much like the
package build cluster. configure script often pick up random libraries
to link against, if these are not recorded as @pkgdep then the package is
mostly useless for other people.

> 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.

Packages are built on a regular basis, I suggest you get more familiar
with the package building and RE process before starting heated
discussions on ports@

> 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. 

I already wrote my thoughts about a FLAVOUR system, where multiple
packages are built per port. Sadly, people seem to think that slave
ports are the way to go. But not only do they eat up precious inodes,
increase the fake count of ports/packages available, and increase INDEX
build times. They are also only deemed worthy for "important" ports,
whatever that means. If you would commit a slave port for every port
that can be built with mysql XOR postgresql, you get an unmaintainable
mess. Not to mention that you violate the "one fact in one place" rule.
Having duplicate ports, that are almost the same scattered throughout
the ports system is obviously not helpful.

> 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.  

There is a dedicated package build cluster, it does in no way interfere
the RE process. Please read up on the mentioned topics, thanks.

Ulrich Spoerlein
-- 
 PGP Key ID: 20FEE9DD				Encrypted mail welcome!
Fingerprint: AEC9 AF5E 01AC 4EE1 8F70  6CBD E76E 2227 20FE E9DD
Which is worse: ignorance or apathy?
Don't know. Don't care.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20060518/8a0b953c/attachment.pgp