Changes

====Add some useful aliases====

====Add some useful aliases====

 

Mezzanine needs to know to use the SourceForge CVS repository in order to checkout/get or import a package. Once a package is checked out from SourceForge, mezzanine/CVS will remember where it came from and check it back into the same CVS repository. You should not set the CVSROOT environment variable as it makes it too easy to accidentally import code into the wrong CVS repository when working with multiple repositories.

Mezzanine needs to know to use the SourceForge CVS repository in order to checkout/get or import a package. Once a package is checked out from SourceForge, mezzanine/CVS will remember where it came from and check it back into the same CVS repository. You should not set the CVSROOT environment variable as it makes it too easy to accidentally import code into the wrong CVS repository when working with multiple repositories.

====Create your work area====

====Create your work area====

 

It is a good idea to perform all of your checkouts in a standard directory hierarchy. This makes it easier to move around between the packages. On a shared build server, it also makes it easier for people to recover your work if required (for example when you are on holidays). If you want to use filesharing to edit files from a networked PC, you might like to use <tt class="FILENAME">~/home/smeserver/</tt>. On a shared build server, you might even use something like <tt class="FILENAME">/builds/users/$LOGNAME/smeserver/</tt> so the files are not in your home directory and are accessible to all developers.

It is a good idea to perform all of your checkouts in a standard directory hierarchy. This makes it easier to move around between the packages. On a shared build server, it also makes it easier for people to recover your work if required (for example when you are on holidays). If you want to use filesharing to edit files from a networked PC, you might like to use <tt class="FILENAME">~/home/smeserver/</tt>. On a shared build server, you might even use something like <tt class="FILENAME">/builds/users/$LOGNAME/smeserver/</tt> so the files are not in your home directory and are accessible to all developers.

{{Note box|msg=Reminder: All files must be checked in using Unix text format.}}

{{Note box|msg=Reminder: All files must be checked in using Unix text format.}}

====mzgetsf_anon: SourceForge anonymous CVS checkout====

====mzgetsf_anon: SourceForge anonymous CVS checkout====

 

You can now retrieve one of the packages from SourceForge. In this case, we want to modify the <var class="LITERAL">smeserver-yum</var> package, so let's retrieve it from SourceForge:

You can now retrieve one of the packages from SourceForge. In this case, we want to modify the <var class="LITERAL">smeserver-yum</var> package, so let's retrieve it from SourceForge:

====Mezzanine package hierarchy====

====Mezzanine package hierarchy====

 

  [gordonr@smebuild smeserver]$ cd smeserver-yum/

  [gordonr@smebuild smeserver]$ cd smeserver-yum/

   

   

====mzclean: Clean out modified files====

====mzclean: Clean out modified files====

 

Before making changes to a package, you should ensure that you have a clean copy of the latest sources. Remember - other people may also be working on the package and making changes in SourceForge. You can perform a "merge" when you check in your changes, but it is easiest to start with an up-to-date copy. It is even possible that someone else has already fixed the bug you are working on!

Before making changes to a package, you should ensure that you have a clean copy of the latest sources. Remember - other people may also be working on the package and making changes in SourceForge. You can perform a "merge" when you check in your changes, but it is easiest to start with an up-to-date copy. It is even possible that someone else has already fixed the bug you are working on!

====mzprep: Build working tree====

====mzprep: Build working tree====

 

The '''mzprep''' command runs '''rpmbuild -bp''' on your SPEC file, sources and patches to generate a working tree. You can make changes in the working tree and use mezzanine to generate the patches between the previous version and your new files.

The '''mzprep''' command runs '''rpmbuild -bp''' on your SPEC file, sources and patches to generate a working tree. You can make changes in the working tree and use mezzanine to generate the patches between the previous version and your new files.

====Modifying a file====

====Modifying a file====

 

OK - now we can actually make a change. We want to modify the file which will be installed as <tt class="FILENAME">/etc/e-smith/events/actions/yum-import-keys</tt>, so the actual file we need to modify is: <tt class="FILENAME">work/smeserver-yum-1.2.0/root/etc/e-smith/events/actions/yum-import-keys</tt>.

OK - now we can actually make a change. We want to modify the file which will be installed as <tt class="FILENAME">/etc/e-smith/events/actions/yum-import-keys</tt>, so the actual file we need to modify is: <tt class="FILENAME">work/smeserver-yum-1.2.0/root/etc/e-smith/events/actions/yum-import-keys</tt>.

====mzpatch: Create a patch====

====mzpatch: Create a patch====

 

Mezzanine automates the creation of patches through the '''mzpatch''' command.

Mezzanine automates the creation of patches through the '''mzpatch''' command.

{{Note box|msg=Always run '''mzpatch''' from the top-level directory of your package (e.g. <tt class="FILENAME">~/smeserver/smeserver-yum/</tt>).}}

{{Note box|msg=Always run '''mzpatch''' from the top-level directory of your package (e.g. <tt class="FILENAME">~/smeserver/smeserver-yum/</tt>).}}

=====mzbuild: Build a new package=====

=====mzbuild: Build a new package=====

 

With all that done, you should be able to build a new package using '''mzbuild'''<nowiki>:</nowiki>

With all that done, you should be able to build a new package using '''mzbuild'''<nowiki>:</nowiki>

====mzgetsf: SourceForge developer CVS checkout====

====mzgetsf: SourceForge developer CVS checkout====

 

Once you have SourceForge CVS access, you can use '''mzgetsf''' (instead of '''mzgetsf_anon''') to retrieve the sources. Your copy will be writable and you will be able to put changes back to CVS. When you run '''mzpatch''' you should not see an error during the '''cvs add''' step.

Once you have SourceForge CVS access, you can use '''mzgetsf''' (instead of '''mzgetsf_anon''') to retrieve the sources. Your copy will be writable and you will be able to put changes back to CVS. When you run '''mzpatch''' you should not see an error during the '''cvs add''' step.

====mzput: Put the changes back to CVS====

====mzput: Put the changes back to CVS====

 

Instead of attaching the patch to the Bugzilla entry, you will be able to put it back to CVS. Mezzanine normally edits the <tt class="FILENAME">ChangeLog</tt>, but we don't need to do that as we keep the changes in the <var class="LITERAL">%changelog</var> section of the <tt class="FILENAME">SPEC</tt> file. The <var class="LITERAL">-m</var> option to '''mzput''' allows a simple comment to be appended, which is all that is required:

Instead of attaching the patch to the Bugzilla entry, you will be able to put it back to CVS. Mezzanine normally edits the <tt class="FILENAME">ChangeLog</tt>, but we don't need to do that as we keep the changes in the <var class="LITERAL">%changelog</var> section of the <tt class="FILENAME">SPEC</tt> file. The <var class="LITERAL">-m</var> option to '''mzput''' allows a simple comment to be appended, which is all that is required: