pkg upgrade?

[Matthew Seaman]

On 03/12/2012 22:10, Walter Hurry wrote:
> I think there's a problem with 'pkg info' irrespective of how the package 
> is built.
> 
> $ pkg info -s -F gcc-4.6.4.20121123.txz
> gcc-4.6.4.20121123 flat size is: 0 B
> gcc-4.6.4.20121123 package size is: 0 B
> $ pkg query -F gcc-4.6.4.20121123.txz %sh
> 567 MB
> $ 
> 
> It seems that 'pkg info' is looking at one measure, while 'pkg query' is 
> looking at another. Maybe portmaster is populating both correctly, but 
> poudriere is only doing one of the two.

No -- the data is stored in the pkg structure in memory in exactly the
same way irrespective of the program used to access it.  The problem
would occur as a fault in converting the value as it is read into or out
of that structure.

The poudriere devs tell me that poudriere doesn't do anything different
when creating packages -- it just uses 'make package' in the usual way
from the ports.  So I now doubt that is the problem.

The fact that 'pkg info' gets it wrong, but 'pkg query' gets it right
implies the problem is localised to 'pkg info'.  That I'm not seeing it
on my dev system, which is running pretty much the latest from the git
repo, suggests that the problem may already have been fixed, although I
can't see a relevant commit message.

> I'm using a straightforward 'pkg create' to build my package files, by 
> the way. But why should there be two (apparently discrete) measures?

It's clear that there is a flaw somewhere, but it's not where I first
thought.  I need to recheck things more thoroughly on my work machine
which I believe was showing the same symptoms. Starting to doubt what I
saw yesterday.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.

PGP: http://www.infracaninophile.co.uk/pgpkey
JID: matthew at infracaninophile.co.uk

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 266 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20121204/81cc91c2/attachment.sig>