Hi Stuart,

Good answer. However, I think this debate needs to be revived from time
to time.

Of course what you are doing is more than good enough for me. I have run
OBSD on a whole bunch of servers since 2.X and probably before. I have
contributed as well. I have also used Solaris, and FBSD on servers, but
prefer OBSD.

I  use FBSD, and compile from source on workstations, but have not done it
for years on servers. I hate Solaris.

regards

Andrew

On 25 October 2014 12:25, Stuart Henderson <[email protected]> wrote:

> On 2014/10/25 09:30, Andrew Grillet wrote:
> > I understand that having a separate headless version is a major change
> > for the whole of ports/packages. However, given that the majority of
> > OBSD installations are probably headless servers, I think is should be
> > seriously considered.
>
> Why? Besides saving ~50MB of disk space, what advantage does it give?
> It's not like these things need an X server to be running, they just
> happen to use some libraries from X.
>
> It isn't simply a case of building things without X support. When that
> thing is a library, you have a whole dependency chain involved, and
> often need to build two versions of those, because enabling/disabling
> things in a library often changes the exported functions, so the
> libraries are not interchangeable. And then, you can't build them
> together in a bulk package build because you'll have some builds
> depending on the X version of a library, others on the no-X, and those
> two versions cannot be installed together. Take this to any length
> and you also hugely increase mirror disk space requirements, user
> confusion, etc.
>
> We've been there before. We used to have no_x11 versions of some
> libraries and we had the above problems, so we removed them.
> Nothing has changed to make them viable now.
>
>    "given that the majority of OBSD installations are probably
>    headless servers",
>
> I don't think we can take that as given. Also note that for many of
> those headless servers, packages are either totally irrelevant, or only
> minimally relevant (for example I have quite a few that only have
> rsync and symon-mon, and actually the latter could now be replaced by
> snmpd in many of those cases).
>
> >                       As it is, Mediatomb is not the only offender.
> > Samba requires Cups (I dont have a printer in the server closet), and
> > Cups requires Xbase too (WTF).
>
> The dependency chain around cups is really delicate and I think it
> already caused quite a few headaches...
>
> > Generally, I am morally opposed to all this "lets just depend on
> > everything on the planet" approach to life because we get the problem
> > of large numbers of simple things depending on different versions of
> > irrelevant software, which could be avoided just by considering whether
> > the relationship is really one of dependency or really one of optional
> > requirement.
>
> If what we're doing isn't good enough for you, you might do better
> with FreeBSD ports where a lot of these things are all build options.
> Of course it means that, because there are so many different
> combinations, you very often *do* have to build it yourself to get
> a particular combination, because the binary packages are only built
> for common mixes. And that burns a lot more than ~50MB of disk space.
>
>

Reply via email to