Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 30 Jan 2005 04:33:56 -0500 (EST)
From:      Tom Huppi <thuppi@huppi.com>
To:        Pat Maddox <pergesu@gmail.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: I only want stable software
Message-ID:  <Pine.BSF.4.58.0501300236410.21778@nuumen.pair.com>
In-Reply-To: <810a540e05012922586675b488@mail.gmail.com>
References:  <810a540e050129021110164a6a@mail.gmail.com> <41FB6685.5040407@mail.ru> <810a540e05012922586675b488@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help



On Sat, 29 Jan 2005, Pat Maddox wrote:

> Thanks for the help there.  I just followed the example in the
> Handbook, though to be honest I'm not quite sure what everything
> means.  Here's my ports-upfile:
> *default host=cvsup2.FreeBSD.org
> *default base=/var/db
> *default prefix=/usr
> *default release=cvs tag=.
> *default delete use-rel-suffix
> *default compress
> ports-all
>
> What updates will I be getting with this?  I want to be able to keep
> my system up to date, and I want to have a lot of the new software,
> but I don't want to be introducing unstable software into my system.
> I want to be able to keep up with PHP and Apache2 as fixes come out,
> but I don't want any experimental stuff running, if that makes sense.
>
> Hope you guys can lend a hand.

Although explained in the various documentation, some of the
nuances and rationals had me confused for quite some time.  This
was especially the case before I understood revision control
systems very well.

It is critical to draw a distinction between the 'operating
system' and the 'ports tree' since the desirable procedures
vis-a-vis staying up to date differ wildly.  The above supfile
will update your _ports tree_ to the 'bleeding edge' or HEAD, and
you would certainly not want to do this with the operating system
('src').  What you have shown is about the only thing which is
practical and available.  You could simply not update your ports
tree (thus missing out on any updates to ports of interest), or
update selected ports, but this effectively renders useless many
of the helpful tools for managing ports, and posses much more risk
of instability unless you are keenly aware of what you are doing.
There is, to my knowledge, no 'tag' which you could use to get
only 'stable' applications.  It would be difficult to maintain
such a collection because the entire (huge) ports collection is a
mass of dependencies and interrelationships and it's a miracle
that it's possible to maintain even one set to the level that the
FreeBSD project does (imho.)

I think that you're best bet is to install only what you think you
need, and research 'stability' on a case by case basis.  Some
Linux package management systems seem to try to characterize
available applications on the basis of 'stability'.  Debian comes
to mind and their research may be a viable resource, but in more
than one case an application so listed as 'unstable' seemed to
work just fine for my purposes (under FreeBSD.)  'Stability' seems
to be in the eye of the beholder :)  This is probably another
reason to not attempt to define a 'stable' ports 'tag'.  The
FreeBSD project does seem to try very hard to track security
issues associated with many of the ported applications, and I
suspect that this is a big job (and a big enough headache by
itself.)

Besides, it's pretty rare for an 'unstable' (a crashing)
application to have an impact on the rest of the OS in my
experience with FreeBSD and Solaris.  The main times I've
experienced stability problems with the FreeBSD OS was when I was
both running a 5.x where 'x' was less than 3, and trying to screw
around with flaky hardware or USB stuff.  In that case, an
application (like 'cdrecord') might provoke and undesirable result
(like a locked up device and a situation where a re-boot was the
path of least resistance.)  Even then, it wasn't that the
application was necessarily 'unstable'.  I suppose that defective
applications with resource leaks in a long-running process could
pose problems.  Again, I think that the best course of action is
to monitor your server now and again, and track the development of
the applications that you run on it.

Now that I think of it, I've currently got one KDE-based
application which, under certain circumstances, can _seem_ to lock
up my X display (but in actuality doesn't really.)  If you are
going to fool around with a lot of disparate applications but have
need for a rock solid production system, it might be worth
considering two systems.  A cheap old machine running headless is
often sufficient for many server duties.

I hope this helps.  I wouldn't even Cc the list except to give
others a chance to correct any potential mis-information.

Thanks,

 - Tom


> On Sat, 29 Jan 2005 13:33:41 +0300, Andrew P. <infofarmer@mail.ru> wrote:
> > Pat Maddox wrote:
> > > I used CVSUP to keep my system up to date.  How do I know that it's
> > > not installing unstable software?  I want to keep my software stable,
> > > but not in the version branching sense.  I just don't want it crashing
> > > my server at all.  Is there any way to ensure that I only install high
> > > quality stable software?
> > >
> >
> > You should use RELENG_4_11 or RELENG_5_3 tags to have cvsup download
> > security patches only. It's probably the most reliable way to keep your
> > system as stable as it gets. Just use the following line in your cvsup
> > supfile:
> >
> > src-all tag=RELENG_5_3
> >
> > You could use tag=. for doc-all, and you should use it for ports-all.
> >
> > Best wishes,
> > Andrew P.
> >
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
>



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