cvsup and versions

[Michael Powell]

wayne mitchell wrote:

> hey,
> i have just cvsup'ed for first time (newbie)

Cvsup as an add-on port is actually no longer needed. Csup is cvsup 
rewritten in C and is a part of the base OS now. Functionally identical.

> RELENG_8_1_RELEASE
> rebuilt world...
> there is a problem with a particular port:
> audio/libsndfile

I am uncertain if you are aware of the difference between 'world' and 
installed ports. The make target of buildworld, buildkernel, etc apply to 
the OS itself and would pertain mostly to OS version upgrades and custom 
kernels. 

This can be reflected in the supfile you might utilize for each purpose. I 
keep 2 different ones, because they pull different bits. By way of example, 
my 'src' supfile for OS source updating will have something along the lines 
of:
[...]
*default release=cvs tag=RELENG_8_2
*default delete use-rel-suffix compress
src-all

The tag RELENG_8_2 is known as the security branch of Release. The only bits 
that change with regard to Release is the inclusion of security update 
patches. The src-all collection contains the OS bits.

My 'ports' supfile has a different tag and collection:
[...]
*default release=cvs tag=.
*default delete use-rel-suffix compress
ports-all

The ports-all collection updates the ports tree. Note the different tag. If 
you were to use this tag _and_ the src-all collection you would be pulling 
the OS bits for -HEAD. When used for ports tree refresh you will always be 
on the most current ports tree at each refresh.

Since dependency tracking comes from the ports tree, each time it 'moves' 
forward (that is applications get newer with version number changes) all 
dependencies slide along for the ride. This is what enables one to utilize 
portupgrade and portmaster to keep installed applciations (and their 
dependencies) updated and matching version-wise.

So most refresh their ports tree immediately prior to adding, installing, or 
updating 3rd party applications, ensuring that everything is always the 
latest and greatest.

The possibility does exist that one may 'freeze' a ports tree in time, 
although not many good reasons for doing so exist. In the ports supfile can 
be added a date parameter which will select a version of the tree as it 
existed at that time. Not something I'd recommend dealing with, per se.


> the version in this system ports tree is 1.0.21
> the set of versions available within the cvs repository are:
>  1.0.20, 1.0.23, 1.0.24 - but not 1.0.21
> 1.0.24 is latest
> it seems that the latest version did not carry across with the cvsup
> i have most documentation available
> have tried portupgrade - no go
> am stuck
> how do i update this individual port
> and is it possible to have two separate versions of same port in the tree
> example: to rename libsndfile dirs to
> libsndfile-1.0.21, libsndfile-1.0.24
> for sake dependancies
> am guessing, though i suspect that the two installed binaries may
> conflict... _______________________________________________

Although not particularly recommended it is possible to have one binary 
version of a lib reported as multiple versions. See man libmap.conf. I 
believe it is better to have recompiled apps linked to the correct lib, e.g. 
libfoo.so.3 may be possibly different enough so that when you lie to app xyz 
it is libfoo.so.2 app xyz may malfunction.

-Mike