portversion and pkg_version have different opinions on current versions

[Matthew Seaman]

Thomas Backman wrote:

> However, a new issue appeared... Kind of. I know I read something about 
> portsnap and INDEX on the -current list recently, so I'm guessing this 
> is related? Maybe not, though (see later in the mail).

> libtool-1.5.26                      !   Comparison failed

This is because the libtool-1.5.x port -- devel/libtool15 -- was renamed
to devel/libtool22 and the port updated to libtool-1.22.x.  See the  
20090802 entry in /usr/ports/UPDATING for special instructions on how to
deal with this.


> So... Using the index causes problems (or the opposite!). Could I be 
> using an index for something like HEAD despite not using that ports 
> tree? (Again, pretty new to this!)

No -- using the INDEX shows you what the INDEX is capable of showing you,
which isn't everything you need to know when using the ports.  You should
get in the habit of casting an eye over /usr/ports/UPDATING any time you
want to do an upgrade.

There is only one ports tree, and you should be using the HEAD of it no matter
what OS version you're running.  There aren't any OS version specific branches
-- just tags to mark the point in time at which support for a particular OS
version was dropped, or to mark the specific set of ports bundled with a release.
HEAD is a continuously moving target -- of the order of a hundred port updates
will be checked in daily largely driven by the availability of new upsteam
versions.

The generated INDEXes are labeled with the OS major version, out of a choice
of 5, 6, 7 or 8 -- which are the only OS versions the ports system is set up
to work with right now.  Actually, I think 5.x support may have been dropped
already.  The choice of 6, 7 or 8 covers all of the supported release branches
and the bleeding edge 8-CURRENT stuff.  Once the release of 8.0-STABLE happens,
and the bleeding edge moves to 9-CURRENT there will be an INDEX-9 generated.
The reason for the difference is that certain ports are not supported on all OS
versions, some have variations in their dependency lists and some have a different
set of default options, so the INDEX comes out differently on the different
versions.

> I don't know how the INDEX files work, but I do know (thank you DTrace) 
> that INDEX-8 was the only one read during "pkg_version -vIL=".

Yes.  You'll only use the INDEX corresponding to the major version of FreeBSD 
that you have installed.  See portindex(5) for details of what the INDEX
contains.

> Oh, and my understanding is that the INDEX-8 is fetched via portsnap? 
> Running the "fetch update" took less than 20 seconds (the cron job ran 
> about 2 hours ago, though), so I guess it cannot have been built (that 
> does take a lot of time, yes?)?

Yes.  Building the INDEX on a fairly beefy machine takes 20min or more and
thrashes disk IO while doing so.  The index available for download by:

    # cd /usr/ports
    # make fetchindex

should be rebuilt approximately hourly, but it isn't unknown for problems to
prevent a new INDEX being available for a number of hours.  I believe the 
INDEXes portsnap supplies are generated similarly.  In fact, depending on the
ports management software you use, the INDEX may be pretty much irrelevant --
portmaster(1) ignores it -- or certain discrepancies may be ignored -- portupgrade(1)
uses data in the INDEX as a guide but double checks against the reality of the
ports tree when working out what needs updating.

If you've made any non-standard settings in /etc/make.conf such as, eg. running
mysql-5.1.x instead of the default mysql-5.0.x or using apache13 or enabling LDAP 
or SASL functionality then you may find it worthwhile to build your own INDEX[*]
as this can help avoid different bits of the system getting conflicting ideas
about exactly what depends on what.

	Cheers,

	Matthew

[*] Modesty prevents me from mentioning ports-mgmt/p5-FreeBSD-Portindex.

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20090815/d20b8242/signature.pgp