Old ports bugs analyzis
uqs at spoerlein.net
Wed Mar 31 16:45:23 UTC 2010
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
More information about the freebsd-ports