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>