www/porttest.html - diff

Return to porttest.html CVS log

Up to [local] / www

Diff for /www/Attic/porttest.html between version 1.6 and 1.7

version 1.6, 2002/09/11 08:49:36

version 1.7, 2002/09/11 09:31:13

Line 51

<h2><a name="First"><font color="#0000e0">First step</font></a></h2>

<p>Before starting you must know that ports development is done by

<p>Before starting the tester must have in mind that ports development is

following <a href="plus.html">OpenBSD-current</a>; you can find

done with <a href="plus.html">OpenBSD-current</a> as target.This means

instructions on following current <a href="anoncvs.html">source</a> and

that there is no guarantee that new ports will work correctly on the other

<a href="faq/upgrade-minifaq.html">upgrade faq</a>. When it's done you

branches. This also means that the tester should upgrade his system to

are ready to follow <a href=

-current as well as the ports tree (instructions on how to do this can be

"mail.html">ports mailing list</a> .</p>

found at the <a href="../anoncvs.html">anoncvs</a> page and in the

proper <a href="./upgrade-minifaq.html">faq section</a>.

Having this done, the system is now prepared to do port testing. It is also

advisable the subscription of ports and ports-changes

<a href="../mail.html">mailing-lists</a>, this way the tester will be notified

about new/updated ports (to be tested) and about changes in the ports

tree.</p>

<h2><a name="Testing"><font color="#0000e0">Testing</font></a></h2>

<p>Now that you are on the mailing-list you can find two types of

<p>In the mailing-lists two types of submission can be found; new ports

submissions; new ports and updates. New ports are generally posted as

and updates. New ports are generally posted as tarball attachment

an attachment or url to a tarball which contains the port tree. A good

(or an url is given) which contains the port tree. A good idea is to extract

idea is to extract it into the <tt>/usr/ports/mystuff/</tt> directory

it into the <tt>/usr/ports/mystuff/</tt> directory and test the port from here.

and then test it. Updates are generally a diff against the current

Updates are generally a diff against current ports tree, so it is suggested

ports tree, so it is suggested that you copy the port into <tt>mystuff/</tt>

to copy the port in <tt>mystuff/</tt> and apply the diff to prevent tree

and apply the diff to prevent breaking your tree.</p>

breakage.</p>

<p>You will need to perform step-by-step the building of the port to

<p>Step-by-step building is needed to verify that every target, see

verify that every target (see

ports(7)</a>) is going correctly :</p>

ports(7)</a>, is achieved correctly :</p>

<ul>

<li>fetch : You just need to verify that distfile(s) are correctly

<li>fetch : Needed to verify that distfile(s) are correctly downloaded.</li>

downloaded.</li>

<li>extract : Generally extract is done without a problem, so you can

<li>extract : Generally extract is done without a problem, this target can

ignore this target in most cases.</li>

be ignored in most cases.</li>

<li>patch : Check if patches apply correctly and track down forgotten

<li>patch : Check if patches are applied correctly and track down

forgotten <tt>.orig</tt> files.</li>

<li>configure : For ports which use a configure script you can verify

<li>configure : For ports which use a configure script the tester can

they have correct path for dependencies, use(less) features, etc

verify if it has the correct path for dependencies, use(less) features,

...</li>

etc ...</li>

<li>build : The build itself should not give errors but could contain

minor warnings about <a href=

Line 94

Line 98

mkstemp(3)</a>.</li>

<li>fake : This target is faking installation of the package to prepare

<li>fake : This target fakes installation of the package and prepares

for packaging. You should verify that files are installed in fake

its installation. Checking can be done by verifying that files are

directory.</li>

properly installed in the fake directory.</li>

<li>package : Package creation can break if pkg/PLIST* and/or

pkg/PFRAG* are wrong.</li>

Line 106

Line 110

<li>deinstall : Don't forget to test deinstall.</li>

</ul>

<p>You could also check some pkg/ stuff like DESCR, MESSAGE, INSTALL,

<p>Checking of pkg/ files like DESCR, MESSAGE, INSTALL,

DEINSTALL</p>

DEINSTALL is also to be done</p>

<h2><a name="Commenting"><font color="#0000e0">Commenting</font></a></h2>

<p>At the end of the test comes the really important thing : comments.

Even if the port is working fine you must comment on it. If we have ten

Even if the port is working fine comments must be done. If we have ten

posts where people say that the port runs fine under different architectures

then the commit is done faster. If it does not work then you must give some

then the commit is done faster. If it does not work then some information

information using tools such as <a href=

must be given.

There are tools that can help in this task, like <a href=

"http://www.openbsd.org/cgi-bin/cvsweb/ports/infrastructure/build/portslogger">

portslogger</a>.</p>

Line 142

Line 147

<h2><a name="More"><font color="#0000e0">More testing</font></a></h2>

<p>For those who are more skilled they can test targets like

<p>Check the port Makefile for typos, incorrect links, useless or

lib-depends-check, look at patches and pkg stuff. You can also provide

missing variables, correct licensing and correct category.

diffs to correct bugs, add flavors, or other enhancements.</p>

For those who are more skilled other targets can be tested like

lib-depends-check. Patches and pkg directories deep verification

as well as providing diffs to correct bugs, add flavors, or other

enhancements.</p>

<hr>