Date: Tue, 18 Aug 2009 18:59:40 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: Anton Shterenlikht <mexas@bristol.ac.uk> Cc: ports@freebsd.org Subject: Re: port science/paraview Message-ID: <4A8AEC0C.8010304@infracaninophile.co.uk> In-Reply-To: <20090818154751.GA1930@mech-cluster241.men.bris.ac.uk> References: <20090818154751.GA1930@mech-cluster241.men.bris.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig74B57AE527C9A7A406AE8060
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Anton Shterenlikht wrote:
> port science/paraview is far behind the current version.
>=20
> I do understand that nobody really takes care of it,
> so please do not see this as a request. I'm grateful
> that somebody has created this port at all!
>=20
> I'd like to help but I've never done any serious
> port work, just occasional patches.
> What is your estimate of the amount of work, and of
> skills required to bring this port up to date?
>=20
> many thanks
>=20
Hmmm... science/paraview is not too complicated as ports go. It uses cma=
ke
which is slightly unusual, and needs a bit of post-hoc modification to fo=
rce
it to install stuff under /usr/local rather than /usr/X11R6 but that's no=
t a
big deal.
If you're capable of configuring, compiling and installing this software
package outside of ports, and you have a fairly minimal amount of familia=
rity
with make(1) and Makefiles, then you stand a good chance of being able to=
generate a set of patches to update the port, and could with a little pra=
ctice
probably go on to become the maintainer.
Remember, the Porter's Handbook is your bible and reference for what all =
those=20
USE_FOO and BAR_ARGS lines in the Makefiles actually mean. Well, that an=
d reading
the contents of the Makefiles in /usr/ports/Mk (these typically have exte=
nsive
comments describing what all the different variables are for) plus compar=
ing
against prior art elsewhere in the ports tree.
To generate an update, I usually work through the following stages:
0) Copy the port directory to a clean workspace somewhere
1) Modify the PORTVERSION and PORTREVISION settings in the Makefile, p=
lus
make any tweaks to MASTER_SITES etc. that are required until you ca=
n=20
successfully run:
# make makesum
This will automatically download the distfiles and update the disti=
nfo file.
For the initial introduction of a new upstream version, any PORTREV=
ISION line
can be deleted, but be sure *not* to touch any PORTEPOCH lines. =20
2) Make sure all prerequisites ({BUILD,RUN,LIB}_DEPENDS) of the port a=
re
installed. To avoid conflicts with other software, it's handy to w=
ork
in a jail but you don't have to. Installing into an alternative PR=
EFIX
and using an alternative PKG_DBDIR and PORT_DBDIR settings is almos=
t as
good. (ie. Prerequisites should go in the standard $LOCALBASE but t=
he port
in question can go into a custom $PREFIX. Usually.)
=20
3) Attempt to build the port:
# make
If it doesn't work smoothly, try and diagnose what the problem is a=
nd fix
it. Repeat until you get a clean build. This is very much the har=
dest
part of updating a port, and can involve significant programming sk=
ills
to write patches etc.
4) Now is a good time to make any edits to pkg-message or other miscel=
laneous
stuff.
5) Make a record of what's installed under $PREFIX:
# find /usr/local -print | sort > /tmp/local-files.before
6) Attempt to install the port
# make install
Again, you may need to apply a few fixups here
7) Record the contents of $PREFIX with the port installed:
# find /usr/local -print | sort > /tmp/local-files.during
8) Now attempt to remove the port:
# make deinstall
If the pkg-plist is wrong, you'll almost certainly see errors here=
=2E
9) Record the contents of $PREFIX after removing the port:
# find /usr/local | sort > /tmp/local-files.after
10) Now, by comparing the differences between /tmp/local-files* it sho=
uld
be fairly obvious what, if any, modifications are needed in pkg-pl=
ist
to account for any differences in the files installed by the newer=
=20
version of the port.
11) Return /usr/local to the state it was in at stage (5) if necessary=
=20
(ie. look at any differences between /tmp/local-files.{before,afte=
r})
12) Repeat from stage (5) until you get a clean install and deinstall.=
You may
or may not need to 'make clean' and rebuild during this cycle depe=
nding on
what you change.
13) Build a package from your port, and test that pkg_add(1) and pkg_d=
elete(1)
will similarly install and remove the port cleanly. (One gotcha i=
s that
pkgs cannot generate empty directories, so it may be necessary to =
add=20
zero-length .placeholder files)
14) 'make clean' in the port. Remove any backup copies of files or ot=
her detritus.
Run portlint(1) and fix up anything it makes a valid complaint abo=
ut.
15) Create a diff against the original copy of the port:
# cd ..
# diff -Nur /usr/ports/science/paraview/ paraview/ > paraview.di=
ff
*Read* *through* the diff file as a sanity check. It's surprising=
how
frequently you'll find a stray copy of an editor backup file has s=
lipped
through at stage (14).
16) Create a problem report, incorporating your diff:
# send-pr -a paraview.diff -P > paraview.pr
# emacs paraview.pr
# send-pr -f paraview.pr=20
When editing the PR, it helps the committers if you can list out a=
ny
added, deleted or renamed files from the port itself. I like to p=
rovide
links to ChangeLogs or similar for the benefit of anyone who does =
their
due dilligence before updating, but that's up to you.
If you're not the port maintainer, then set the PR as a 'change-re=
quest'
If there is a listed maintainer, you can CC them in the PR, but th=
e ports
automation will send them e-mail anyhow. If this is an update to =
close a
publicised security hole, then CC'ing secteam@freebsd.org is helpf=
ul. (If
it's not a /publicised/ security hole, then it's better to contact=
the port
maintainer or secteam@ privately rather than submitting an update =
through
a public channel like the FreeBSD PR system).
=20
You should receive an acknowledgement from Gnats with a PR number in =
about 15
minutes. A committer will generally take the PR within a few hours a=
nd add it
to their tinderbox queue for testing. If they are happy and everythi=
ng works
satisfactorily, then the update will generally be committed within ab=
out a week.
Do this successfully enough times with unmaintained ports, and you wi=
ll likely be=20
offered maintainership when you submit updates. Volunteer to maintai=
n a number
of ports and keep supplying a good stream of correct updates and you'=
re well on
the slippery slope towards having a commit bit and an @freebsd.org a=
ddress
thrust upon you...
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enig74B57AE527C9A7A406AE8060
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkqK7BIACgkQ8Mjk52CukIwBwwCfUZoPSoJSkJAEhzGPf41nnh/9
Gm0AnAowrdmgl96ImnC7ChtIAKG/I3+U
=OAWj
-----END PGP SIGNATURE-----
--------------enig74B57AE527C9A7A406AE8060--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A8AEC0C.8010304>