Old ports bugs analyzis

[Ulrich Spörlein]

On Wed, 31.03.2010 at 14:28:46 +0400, Arseny Nasokin wrote:
> I've talked about custom built-in settings. Different options are need  
> in different situations. We doesn't have any real statistics about  
> options use.
> 
> For example, gvim(1) is good idea on most desktop systems, but after  
> some issue, I build vim without GUI support. Issue is simple:
> 
> Start x11, run xterm, run screen in it, detach, shutdown x11 server.  
> Attach to screen from text mode and run vim. You'll get at least  
> warning and slow startup.
> Second issue about is why should X11 be on headless server?
> 
> What should we do in this case? Create 10-20 packages for every  
> program? Or provide customisation interface (ports tree)?
> 
> If second we can provide ports tree, which can download prebuild  
> package if common options are used or build it in other case or if  
> user want it. 

This has been floated around in this thread as "fat packages", where you
basically have the build cluster build a port, eg. three ways. In our
case vim-lite (no x11), vim (gui) and vim-full (perl, cscope, ...).
These three runs can than be combined into one fat package. As they
share documentation and other "share/" data, only the binaries/libraries
need to be stored 3x in the package and compression should nullify the
.tbz growth further.

Same could be done for mplayer, an mplayer-full "flavour" an
mplayer-free flavour using only free codecs, etc. Similar things can be
done for mysql's or openldap's -client and -server packages.

In summary, pkg_add vim on a server without X11 libs can then decide to
extract the non-X11 variant, while someone on a desktop system will get
a bigger version.

This however, needs better pkg_ tools, more/faster hardware in the build
cluster and a ton of volunteer work that is hard to come by these days
...

Regards,
Uli