Questions about port revision numbers, portsnap, csup

Matthew Seaman m.seaman at infracaninophile.co.uk
Mon Apr 19 18:05:28 UTC 2010


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19/04/2010 18:10:36, Joe Auty wrote:
> Hello,
> 
> I've identified my pecl-APC install as being broken after upgrading to
> PHP 5.3.2. According to the commit history listed here:
> http://www.freshports.org/www/pecl-APC/ there is a fix out. However,
> doing a portsnap fetch update does not seem to fetch this latest
> revision to this port, after doing my portsnap it shows no updates are
> available for the port although I'm pretty certain that I last
> portsnapped before April 12. I'm assuming that portsnap only grabs a new
> version of the portrevision number has been bumped?
> 
> My questions:
> 
> 1) If I were to csup my ports tree to force a fetch of this update,
> would this break portsnap?
> 
> 2) Is there a way to look at the commit history of the ports I have
> installed in /usr/ports so that I can verify whether or not I have the
> revision with this particular fix? Thus far I've been relying on
> freshports.org and trusting that doing a portsnap will always fetch the
> latest stuff visible on freshports.org, but now I'm not so sure...
> 
> 3) Shouldn't the portrevision number be bumped whenever there is an
> update? I always assumed that the _x suffixes indicated a portrevision
> bump. Why was it not bumped for this pecl-APC fix? Human error? Is there
> any other way I can force the download of this port, or is csup my best bet?

The only change in the last update (12th April) to pecl-APC was the
addition of files/patch-php_apc.c

That's good in the sense that you can simply download that file from CVS
and put it into the files sub directory if it isn't there already and
then force a rebuild of the port to get the benefit.  Note that running
portsnap after doing that could blow away the patch file if portsnap
really is missing it.  However, I suspect that it is known to portsnap
and that something else is wrong with your build.

You could change to using csup rather than portsnap, but be aware that
this pretty much means scrubbing all of your portsnap state.  Indeed,
for best results with csup, starting with an empty /usr/ports might be
an idea -- I don't think that will be necessary, but I can't be certain.
 If you switch to csup, switching back to portsnap will definitely
require you to re-download the ports tree and replace everything you had
installed via csup.  In any case, I don't think the problem you're
experiencing is sufficient justification for making such a sweeping
change -- both portsnap and csup are effective at what they do, and
losing a whole file would be a pretty disastrous failure.

Since the port revision number wasn't bumped on 12th April, you'll have
to check the oldest date on files inside /var/db/pkg/pecl-APC-3.0.19 --
don't check the date on the directory itself: the normal operation of
portupgrade(1) will modify it.

The rule about PORTREVISION numbers is that they should be applied when
the update causes a material difference in the state of the installed
port.  Fixing a problem that stops the port compiling at all doesn't
usually count: some maintainers/committers might bump portrevision,
others wouldn't.

	Cheers,

	Matthew

- -- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkvMmxUACgkQ8Mjk52CukIyHJACfVrNIjL8p/CgY59e6S/xo+jX4
sNoAn2+7bEKxr42Ta5Jn7zbWEnKz5HUZ
=Fevg
-----END PGP SIGNATURE-----


More information about the freebsd-questions mailing list