Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 14 Oct 2004 10:50:41 -0300
From:      Fernan Aguero <fernan@iib.unsam.edu.ar>
To:        FreeBSD Ports <ports@FreeBSD.ORG>
Subject:   Re: alternative options for ports
Message-ID:  <20041014135041.GB4625@iib.unsam.edu.ar>
In-Reply-To: <20041014095355.GA61134@elendil.ru>
References:  <416C0DE8.3000004@struchtrup.com> <416C35A5.4040703@vonostingroup.com> <20041013123840.GB1301@FreeBSD.org> <20041013193432.GA53895@hub.freebsd.org> <416DAB52.5070404@struchtrup.com> <416DAD75.7000504@vonostingroup.com> <416DB213.3020708@struchtrup.com> <20041014095355.GA61134@elendil.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
+----[ Sergei Kolobov <sergei@freebsd.org> (14.Oct.2004 07:02):
|
| AFAIK, OpenBSD has a feature called "port flavours" (if I'm not mistaken).
| I confess I haven't look into it in detail (yet) but it looks like 
| it does exactly what you describe. That is, the port Makefile specifies 
| something like:
| 
| FLAVOURS=	gtk kde athena
| 
| which produces the corresponding vim-gtk, vim-kde, and vim-athena packages
| from a *signle* port, without a need to create a multitude of slave ports.
| 
| Is there anybody working to bring this feature in our bsd.port.mk?
| 
| Sergei
|
+----]

Hi! seems like everybody is jumping on this wagon ... and so
am I :)

I'd like to address the issue of building a number of binary
packages from a given port, each built with a different set
of options.

IMHO, what we're discussing here, as many people more or less
directly pointed out, are the differences between a binary
oriented installation system, versus the source oriented
FreeBSD ports system.

I've used Linux in the past and was always uncomfortable
with the myriad of rpm packages available for a given piece
of software. This is what you get when you build a port many
times, each time with a different options set and produce
every possible (or nearly every possible) binary package.

Users get lost. Even when you know what you want ... you
have to search for _that_ specific package that was built
and packaged the way you wanted. 

In many cases the binary packages available from the vendors
(redhat, debian, etc.) only provide packages with the most
common options. There are also third party binary packages,
contributed by volunteers, but in this case you can't
trust the packages the same way that you can trust a FreeBSD
binary package. The FreeBSD ports are peer-reviewed, the
contrib RPMs are not.

Thus, you always end up reasoning that building from source
is the way to go, if you want to have control over the
resulting binaries. Even in binary oriented systems.

IMO, in the context of any big project, be it source or
binary oriented (FreeBSD, Linux, etc) producing this variety
of packages may not be desirable or even sustainable in the
long term (although this of course depends on the volume of
users and volunteers). In the case of binary oriented
systems, there is a reasonable need to provide a number of
different packages for a given 'port'. In the case of a
source oriented system, there is no such a need.  However,
it might be _convenient_ to have already built packages. This
is more evident in big ports, that need lots of time and
disk space to compile.

Summing up, and again IMO, having a variety of packages, or
slave ports is just going to bring noise into the ports
system. 

I'm perfectly comfortable with one XXX port. I know the
options are in there, and I can tune it the way I like. I
can then build binary packages for internal distribution to
all the systems I manage. 

I'm not comfortable with one XXX port and several XXX-XYZ
slave ports. I like to think of this issue as another kind
of 'security through obscurity', though perhaps its reversal
(here the idea is to make things as clear/easy as possible).
A port with many options is complex. Period. Providing
custom build packages and/or slave ports is like trying to
hide this complexity.  OTOH, having a single port with many
options, though complex, has the advantage of making it
clear to the user that the complexity is there, and that
s/he has to deal with it (i.e. it has the advantage of
making the user aware of the issue we're discussing here).
Options help to deal with it, and I think this thread is
about making options work better.
[I may be oversimplifying, since I'm not addressing any
specific case ... perhaps my reasoning fits well for some
ports and not too well for others ...]

Fernan

PS: english is not my native language. I try to get the
meaning through, though sometimes the words I chose might
not 

-- 
Fernan Aguero -  fernan at iib.unsam.edu.ar
Phone: +54 11 4580-7255/7 ext 310, Fax: +54 11 4752-9639
Check http://genoma.unsam.edu.ar/~fernan for more info.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041014135041.GB4625>