dependency explosions

[Grzegorz Junka]

On 03/10/2016 14:48, Mathieu Arnold wrote:
> Le 03/10/2016 à 16:29, Grzegorz Junka a écrit :
>> On 03/10/2016 14:11, Mike Clarke wrote:
>>> On Mon, 3 Oct 2016 13:11:43 +0000
>>> Grzegorz Junka <list1 at gjunka.com> wrote:
>>>
>>>> Shouldn't all packages default to noX dependencies? If I am not
>>>> mistaken
>>>> FreeBSD is predominantly a server-side system, with X running only
>>>> occasionally
>>> I'd disagree with that. I don't know whether or not the majority of
>>> FreeBSD installations are servers or personal computers but the chances
>>> are that the majority of server installations will have relatively few
>>> packages installed whereas most PC's are likely to make use of far
>>> more packages and are also likely to be using X. Building from ports
>>> to get the required options would be a much bigger task for these
>>> installations than it would be for the servers.
>>>
>> I have been wondering if it would be possible to have two distinct set
>> of packages compiled automatically, one tailored for X and one for the
>> console. It seems that requirements of both environment are quite
>> opposite. The server-side requires small amount of packages without X
>> because it wants to run the system headless, as long as possible and
>> without interruptions and restarts. Whereas the X/PC environment
>> always wants to have everything latest and newest. In the Linux world
>> they would just create a new distribution, even in the BSD world there
>> is PC-BSD/TrueOS. But we have ports and can re-use the same base for
>> two distinctive set of packages. I don't believe we can create
>> pre-compiled packages for FreeBSD in such a way, that both camps are
>> happy (which this thread is one of many signs of).
> The FreeBSD project cannot provide more than one set of packages. If we
> went that way, we would end up having to provide, say, [with X, without
> X]x[apache 2.2, apache 2.4]x[php56, php70]x[postgresql 9.3, 9.4, 9.5,
> 9.6]x[insert 5 flavors of mysql]x[openssl, libressl]... I'm sure I can
> find other kind of options, and that is already 320 sets.
> Right now, we build packages for
> [9,10,11,12]x[amd64,i386]x[head,quarterly], that's 16 different sets,
> and we mostly manage to build them over and over again, every two days.
> Imagine how long it would take to build 320 sets.
>

You are trying to take that into extreme to ridicule this as an option. 
You can't possibly build 320 sets, even if you had enough build 
machines, because each set would need to contain incompatible packages. 
If you choose, say, php56 as the default, then you can't possibly 
install a package that depends on php70. The amount of combinations 
would expand exponentially. It would be like having 320 different 
incompatible sets of packages to test.

The same with packages that depend on X. Sure, if you install 
emacs-nox11 you can still install other packages that depend on X, but 
at some point it would start to break, e.g. you wouldn't be able to 
install ImageMagick-nox11 and ImageMagick at the same time.

What I proposed is to have two sets of packages, one for server use 
(noX, maybe other defaults) and one for desktop use (X, multimedia, 
maybe other defaults). You usually don't switch a machine that's working 
as a desktop workstation to suddenly become a rack server in some data 
center.

Grzegorz