** don't go there: this imposes a significant amount of maintenance work and may still break. Rather provide large enough base sets and accept that some packages install too much (you can still disable them at runtime) and build the few deviations from the rule on the servers from source --[[User:Tiziano|Tiziano]] ([[User talk:Tiziano|talk]]) 14:39, 3 January 2014 (CET)
*** Yes, we need to and can go there :-) I agree with you, that we should do this only if necessary, apache for example can be built once and has the ability to turn features (module loading) on/off via its configuration. Other software does not provide such run-time configuration which results in unwanted server-software and dependencies on the installed hosts (<code>net-analyzer/zabbix</code> for example). I clearly do not want to have a dedicated build environment for each of those packages, I would rather see a build env, called minimal for example, which is used to build all those database packages with only lib and clients enabled (use the same env for PostgreSQL, OpenLDAP, MySQL etc.). As stated before, the whole build process needs to be automated, so I don't see a considerable increase of maintenance work coming up here. The dependency problem is mitigated through the fact that we have a frozen portage tree for all our build envs and therefore use the same versions everywhere. --[[User:Chrigu|Chrigu]] ([[User talk:Chrigu|talk]]) 12:04, 6 January 2014 (CET)
*** Yes and no on this one. We clearly need to keep the list of packages that require this at bare minimum. <code>net-analyzer/zabbix</code> for instance doesn't warrant this, we just won't start the server on non server nodes. Easy as cake. The server code and it's deps wont do any harm on say a desktop or other server box. Even though I can't think of example, I do believe we will be needing this possibility when we encounter packages that need to be built using different profiles for different use cases, things like having a php with-curlwrappers vs one with the curl module sans curlwrappers. The important point I take from this is that creating new profiles with small deviations from our default must be very easy (ie. not much work). Basically we need the infras support for n different build profiles to be fully automated and well documented. [[User:Lucas|Lucas]] ([[User talk:Lucas|talk]]) 19:52, 9 January 2014 (CET)
* Providing binary packages for different major (and sometimes minor) versions, for example: <code>dev-db/mysql-5.X.Y</code> and <code>dev-db/mysql-6.X.Y</code>.
* Provide binary packages for pre-compiled Linux kernels and modules (not just a binary package of <code>sys-kernel/gentoo-sources</code>)
** This makes it possible to build stage4 images from binary packages.
** Most likely there will be separate packages for servers and desktops built with different genkernel configs.
* Handle reverse dependency updates and ABI changes