On 2004-06-19 10:58, Patrick Useldinger <[EMAIL PROTECTED]> wrote:
> Giorgos Keramidas wrote:
> > Before I answer to this question, I cannot help noting that you don't
> > *HAVE* to compile everything from source.  In fact, if you install a
> > RELEASE version of FreeBSD and use pkg_add to install the binary,
> > precompiled packages of just the applications you are going to
> > use... there is absolutely no need to rebuild anything from source.
> True for the CDs. But once you want to upgrade, things get more
> complicated. For example, I did not find a package for OpenOffice 1.1.1
> in the "offical" places, although OO is certainly an excellent candidate
> for a package.

Indeed, packages-4-stable, packages-4.10-release on ftp.freebsd.org
don't include openoffice.  A search at google though yields:


which does list FreeBSD packages of OO-1.0.3 and OO-1.1.0 :-)

> This led me to the conclusion that packages, in the FBSD world, are
> considered less important than the very well maintained ports.

The ports people are going through a lot of effort to build, test and
package the maximum possible number of ports before each release.

> I would prefer it to be the other way round: go for packages, unless you
> want to tweak anything.

This is preferable from the end-user's perspective, but I think it would
exponentially increase the number of precompiled binaries the mirrors
would have to keep available.  If a port has 3 options and depends on
another with 4 options, to host every possible combination that one
might want on the FTP site 12 different combinations would have to be
built and packaged!  With thousands of ports in the tree this means a
mind-boggingly huge number of different builds and packages can be built.

Is it possible to satisfy all the users with precompiled packages?  No.

So, going for ports and using packages only is a bit difficult :-/

> I do not agree with an earlier argument, which was that you could change
> the source. I have been programming for 25 years now, I am certain that
> you don't change code, not even in a reasonably sized project, without
> spending a large amount of time.

I have a local patch to fetchmail in my local /usr/ports tree that fixes
a bug recent versions have with APOP:

: [EMAIL PROTECTED]:05]/usr/ports/mail/fetchmail# cvs -q up -APd
: ? files/patch-zz::apop_bug
: [EMAIL PROTECTED]:05]/usr/ports/mail/fetchmail#
: [EMAIL PROTECTED]:06]/usr/ports/mail/fetchmail# cat files/patch-zz\:\:apop_bug
: --- driver.c.orig     Sun Mar 28 13:29:15 2004
: +++ driver.c  Sun Mar 28 13:49:42 2004
: @@ -429,7 +429,7 @@
:       /* for POP3, we can get the size of one mail only! Unfortunately, this
:        * protocol specific test cannot be done elsewhere as the protocol
:        * could be "auto". */
: -     if (ctl->server.protocol == P_POP3)
: +     if (ctl->server.protocol == P_POP3 || ctl->server.protocol == P_APOP || 
ctl->server.protocol == P_RPOP)
:           fetchsizelimit = 1;
:       /* Time to allocate memory to store the sizes */

This is a serious showstopper for anyone who uses fetchmail and doesn't
want to fetch all the messages in one connection (for whatever reasons).

It didn't take me more than 15 minutes to write, but then I'm working as
a programmer so that's "normal".  Fetchmail is, IMHO, a reasonably sized
project.  I'm not saying this to sound insulting to you in any way, or
to boast about my ''l33t h4x0r skillz'' -- that's nonsense.  I am only
bringing it up as a good example where building the port *does* have
obvious advantages.

- Giorgos

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to