> -----Original Message-----
> [mailto:[EMAIL PROTECTED] Behalf Of Gonzalo Nemmi
> Sent: Wednesday, July 23, 2008 1:02 AM
> To: freebsd-questions@freebsd.org
> Subject: Re: FreeBSD for webserver?
> On Wednesday 23 July 2008 03:47:04 Ted Mittelstaedt wrote:
> > > This seems to be a common misperception about ports.  Ports
> > > aren't something
> > > magical.  They do exactly what you would do from the commandline (i.e.
> > > ./configure, make, make install), except they come with
> several bonuses.
> > >
> > > 1) The port maintainer has already worked out all the quirks to
> > > make it compile
> > > and install properly on FreeBSD.  2) The port maintainer has
> > > already supplied
> > > patches that allow the software to build correctly on FreeBSD.
> > > 3) All the
> > > dependencies are already taken care of.  4) Upgrading is
> quite simple and
> > > straightforward.  5) The software is now
> > > architechture-independent (in most
> > > cases), meaning you can move from Intel to AMD (for example)
> > > without having to
> > > worry that the software will no longer build and you'll have to
> > > start from
> > > scratch again.
> > >
> > > For example, I decided today that I wanted to try out some
> software named
> > > "arguseye".  So I downloaded and untarred the program.  I
> looked at the
> > > dependencies.  It requires a number of perl modules, some of
> > > which are not in
> > > ports.  So, I just created three new perl ports to satisfy those
> > > dependencies
> > > and submitted them this afternoon.
> > >
> > > Once those are accepted into the tree, I'll create the arguseye
> > > port and submit
> > > it as well.  Then, when someone else wants to install arguseye,
> > > all they will
> > > have to do is type "make install clean" in the port directory and
> > > everything
> > > that they need will be installed for them.
> > >
> > > Unless you're a glutton for punishment, why would you do all that
> > > yourself?
> >
> > Because maybe you don't care for the porter's choice of defaults.
> >
> > Many programs come with hard-coded defaults that are modified
> > in a config file.  For example cistron-radius.  Another example
> > is the dspam port.  The porter for that insisted on using a
> > default of apache vhost.  However the default apache port does
> > not activate this.  I don't give a rat's ass that vhost is
> > supposedly more secure.  Another one that always pisses me off
> > is the porter's choice in building uw-imap to turn off plaintext
> > passwords.  And the default for pine is also to turn off
> > plaintext support.
> >
> > Another problem is that not all porters are good about maintaining
> > their ports.  For example icradius.  Someone spent a lot of time
> > creating the port for that.  Then just let it die.  Another is
> > the open source ingres database.  Julian ported that one then
> > lost interest, it died sometime around FBSD 4.X
> >
> > Another problem with ports is that all of them like pulling the
> > original source from the author's site.  I've had a few where the
> > author released the code under GPL then a few years later lost
> > interest, stopped paying whatever ISP he had the main site for
> > the program at, and the porter also lost interest in the project
> > and never bothered obtaining the last available tarfile from
> > the authors site and uploading it to freebsd, then both disappeared.
> > Another one I can recall is the gated code, similar issue.
> >
> > The fundamental achillies heel of the ports system is it makes
> > the assumption that every package in the ports system is popular
> > and will be supported for the indefinite future by the original
> > package developer.  The ports system counts on this insofar that
> > it assumes that if the original porter loses interest and stops
> > tracking the master site, that someone else will step in and
> > assume responsibility for maintaining the port.
> >
> > The reality is that in every release of FreeBSD, some ports go
> > wanting for sponsors, and nobody steps forward and so when the
> > port stops building, the FreeBSD maintainers simply cut it out
> > of the ports tree, plus anything dependent on it.
> >
> > This assumption is fine for people running vanilla apache or
> > whatever systems, which is most people.  But, if your doing
> > anything that isn't plain-jane middle of the road, you better
> > assume that if your using a series of ports, to make detailed
> > notes, and save the ports, and save the patches, and save
> > the distfiles.  You may need to see how they did it in an
> > older FreeBSD system when a new version of FreeBSD comes out
> > that is missing one or more of the ports you depend on.
> >
> > Ultimately, ports isn't any different than most other things.
> > When it's properly executed it's great.  But proper execution
> > of the entire thing depends on every porter who has an active
> > port in the system doing the right thing, and there's so many of
> > them that statistically, some of them are going to be flakes.
> >
> > Ultimately, if your going to be a server admin, you need to
> > know how to build your applications without ports.
> >
> > It's no different than, for example, I know how to pour and
> > form concrete, I know how to plumb pipes.  But if I needed
> > concrete poured, or pipes plumbed, I would call a contractor
> > and a plumber, and because I know how to do these things I
> > would be able to keep an eye on what the people I hired
> > were doing and know if they were doing what they were supposed
> > to be doing, or if they were incompetents.
> >
> > The folks that depend utterly on ports and have no notion of
> > how to build it manually, are like the people who don't know
> > how to pour concrete or plumb pipes, and who hire a mason and
> > a plumber anyway.  They think they are having their concrete
> > and pipes done, but in reality they have no clue if the
> > work is really being done properly or not.  And, years later
> > that concrete may be cracked and the pipes leaking, and
> > they have no clue if it was due to crap work or something else.
> >
> > Ted
> >
> > _______________________________________________
> > freebsd-questions@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> > To unsubscribe, send any mail to
> Ted, with all due respect, you do have pointed out some valid
> points .. yet,
> there is a mailig list for that matter...
> http://lists.freebsd.org/mailman/listinfo/freebsd-ports
> you seem to be pretty knowledgable about certain aspects that
> others don't
> even came across simply because we don't run into those problems
> because we
> don't need or use a given piece of software ...

Your taking quite a leap to be speaking for "we" on this list,
are you quite sure that everyone else does not run into these
problems? ;-)

What I was speaking about is a structural issue that is not a
problem with ports per-se, it is a problem with how ports are USED.

Ports is a great tool, I can't speak highly enough of it.  However
like ALL tools, if not used properly it will not work very well

It does not help to jump on the ports mailing list and bitch about
how people use the tool. The folks that built ports cannot control
if a porter loses interest in his port and nobody else picks it
up.  They cannot write a technical fix for this, it is a human problem.
However that human, not software, problem will affect YOU if you
happen to be using that port, just as sure as a technical software
build problem in the port manager would.

Like all things in life it is fine as long as you understand what
your doing and all the implications of using a prewritten set of
instructions.  But there is more to the eye than just CD /usr/ports/whatever
and typing make install, and folks on this list that just say that
is all there is to it are doing a disservice to a newbie.

> It's my experience ( and of course, YMMV ...) that por
> maintainers do answer
> e-mails and fix stuff when asked to do so .. It happened to me at least :)

Most do but not all.  As I said there is always a list of ports in
every BSD release that
the mangers drop as a result of the port maintainer not responding
to e-mails to fix a build.

> Yet, some (maybe even most) of your observations still stand true ...
> Whoever .. as it has been criteriously pointed out by Paul Schmehl:
> "There are certainly special cases where compiling from source is
> preferable, especially if you have a highly customized installation, but
> those are the exceptions rather than the rule."
> And I do agree with that statement ... to put it simple:
> exceptions can never
> be taken as a basis for general rule ...

Which is why I said that "this assumption is fine for people running vanilla
apache or whatever systems, which is most people."

> Still, should you be kind enough .. I'd like to invite you to post those
> issues on freebsd-ports for all of us to know about them and then be in a
> position to discuss those issues in due time .. because evetually
> ... those
> will bite some of us sooner or later ...

Any experienced FreeBSD porter already knows about this.  And there is
no fix other than to attempt to force people to take over ports that
are abandonded, which wouldn't work and is certainly contrary to the
FreeBSD spirit.  Essentially this is a problem that affects ANY open
source package including Linux, so it's not really on topic in a
narrow group like ports.  It's just something to be aware of when
using ports, or any OSS, just like you have to be aware of the Microsoft
Product Lifecycle if you use Windows.


freebsd-questions@freebsd.org mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to