On 9/7/07, Lars Eighner <[EMAIL PROTECTED]> wrote:
> On Fri, 7 Sep 2007, cothrige wrote:
> > assumption that one must run two cvsup operations with two separate
> > supfiles to update both the core OS and the ports.  Am I understanding
> > this correctly?
> No.  It is not "must."  You "can" update your source and your ports tree
> with one supfile.  You can add the line
> Many people do it it two operations because they really are two different
> things.

Okay, that seems to confirm my basic understanding then.  I must
readily admit that the overall application is a bit above me at this
point (it is certainly more complicated than the "aptitude update" and
"aptitude upgrade" that I am used to.).  At least though I appear to
be on the right track about how the two are different entities in some

> There is no necessary, hard and fast, connection between the two.  If your
> ports tree gets very, very stale, it will largely cease to work because
> many (some) of the source files will disappear or their dependencies will
> disappear or change.

Okay, this makes sense to me.

> General, upgrading the OS is a good idea about six months after the second
> release of a major version number (i.e. when 7.2 or 7.3 is a release and is
> about six-months old).

So, you would say that there is no pressing need to update the OS yet?

> > If I don't want to run stable and use "tag=RELENG_6_2" will I
> > be required to keep the ports as they have installed from the disc?
> No.  In fact you shouldn't. (But as mentioned above, never use any tag with
> ports except ".".)  Of course there are two different things here that you
> might be confusing.  The ports tree, which is a skeleton for building
> applications from scratch, and packages, which are pre-built binaries for
> applications.

Yes, I think I am probably confusing them at least to a degree.
Probably that is because it just seems logical that the packages would
match what is in the ports tree and it is hard for me to imagine it
may not be the case.  If my ports tree has a particular version of an
app in it, say mplayer-1.0.7 wouldn't the package available be the
same?  I also wonder about this because portupgrade, which is
obviously for ports, does have the option for using packages.  It does
make me wonder, how does pkg_add or portupgrade know which versions of
which packages to retrieve, as opposed to using the port to know which
version of the port to install?  Does that make sense?  I feel like I
am being very awkward in my wording, and I apologize for not being
more clear in it.

> Here's the best way to install 6.2 starting with the CD release (assuming
> you have internet connectivity which I guess you do since you mailed to this
> list).
> 1.  Install 6.2 including source, but do not install Xorg.
> 6.  Install Xorg (and other applications you may want) from the ports tree.

Very good to know.  Unfortunately, I did not use this way to get
started, but next time I will certainly follow your suggestions as
even now I can see how they would help.  Installing X from the disc
was not the best choice, but being used to Linux installers it seemed
logical at the time.  As did installing the ports tree.

> The main object is to keep the ports in synch with other ports.
> There are just a few ports that do things (like build loadable kernel
> modules) which just won't work if they are too out of synch with the
> operating system, but these are few and far between.

I think I understand.  So, I can update the ports x number of times
per a given period of time, but I don't have to update the OS as
often.  They are not so intimately connected that I have to keep them
in sync somehow with one another, and therefore updating them at
different rates will not cause breakage, am I right?

> > When I first finished setting things up
> > I could install packages using "pkg_add -r", but noticed that after
> > updating the ports I could no longer do that....
> More than likely the packages were broken.  Often the available packages are
> way out of date or do not exist (because of licensing restrictions or no one
> got around to building them).  Packages depend to much greater extent on the
> OS release.

Very interesting.  But, could that really explain a 100% failure rate?
 In my previous experience with FreeBSD I became convinced that I had
broken things badly since after updating I was unable to use even one
package.  I mean, no big deal in itself, and if the system had no
package options I would have no real complaint.  But, it just seemed
broken as it was, and so I was convinced that I had done something

> Portsnap is a different system from cvsup.  They should get approximately
> the same tree (not exactly the same because the ports tree changes so
> rapidly).  Portsnap is usually run automatically (as a cron job) every few
> days, or oftener if you are really complusive.  It is said to save
> bandwidth if used this way, so if you are administering a large system, it
> probably pays off.  If this is your home desktop, you probably aren't adding
> or upgrading ports every day (but there are always some people who spend
> more time customizing their cars than riding in them) and cvsup is perhaps
> better suited for occasional spells of upgrading.

Good to know.  Thanks for the info on all of this.

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

Reply via email to