Clarified the EXTENDED DESCRIPTION section of the manpage and enforced more consistent highlighting of ``sunrise-commit''.

This commit is contained in:
Nathan Phillip Brink 2010-10-30 16:34:32 -04:00
parent dbd11bc848
commit f8ea18212e

View File

@ -103,47 +103,54 @@ The sunrise-suggested format is:
.SH "EXTENDED DESCRIPTION"
.IP "Adding packages"
.IP "Adding and Updating Packages"
The primary use of sunrise-commit is to commit packages to a repository.
In order to use it in this scenario, you are expected to run it from
within the package directory (one with the ebuilds), providing
an appropriate changelog message.
The primary use of \fBsunrise-commit\fP is to add packages to a Gentoo
repository or update existing packages. In order to use it this way,
you are expected to run it from within the package's directory,
providing an appropriate changelog message. (The package's directory
is the directory holding its ebuilds).
If your package requires an additional file to be committed outside
the package directory (e.g. an eclass, a license) you need to commit it
manually \fBbefore\fP using sunrise-commit.
the package directory (e.g. an eclass, a license), then you need to
commit that file manually \fBbefore\fP using \fBsunrise-commit\fP.
What sunrise-commit will do for you is the ChangeLog entry and calling
repoman to do the actual commit. If you think your commit doesn't
deserve a ChangeLog entry, use \fB--trivial\fP.
\fBsunrise-commit\fP will update the ChangeLog entry and call
.BR repoman (1)
to do the actual commit for you. If the package's ChangeLog should
\fBnot\fP be updated for a particular commit, use \fB--trivial\fP.
If you're adding a new package, it may be also necessary to use
\fB--noupdate\fP to avoid calling VCS update command as it could fail
with a freshly created directory (especially with subversion).
If you are adding a new package and using subversion or a similar VCS,
you may get a warning that your VCS's update command failed. For
example, subversion's update command fails when run from a newly added,
but not yet committed, directory. To avoid this warning, you may use
\fB--noupdate\fP. This option prevents \fBsunrise-commit\fP from calling the
VCS's update command (which only happens if you are not using DVCS).
.IP "Removing packages"
.IP "Removing Packages"
sunrise-commit can be used to remove a set of packages too. In order to
do so, first mark all the expected packages removed using your VCS.
Perform the necessary \fBpackage.mask\fP changes too, and remove
\fBsunrise-commit\fP can be used to remove a set of packages too. In order to
do so, first mark all the expected packages as removed using your VCS.
Next, perform the necessary \fBpackage.mask\fP changes and remove
licenses no longer in use.
Afterwards, call \fBsunrise-commit\fP from within your repository root
directory, passing the removal reason. The script will prepend it with
the complete removed package list.
Afterwards, call \fBsunrise-commit\fP from within your repository's root
directory, passing the removal reason as an argument. The script will
prepend your commit message with the complete removed package list.
Please notice that it will commit all changes in \fBeclass\fP,
\fBlicenses\fP and \fBprofiles\fP directories too. This is in order to
accomodate the need of removing \fBpackage.mask\fP entries and unused
files but could cause trouble if the working copy is dirty.
Please note that all changes in the \fBeclass\fP, \fBlicenses\fP, and
\fBprofiles\fP directories will be committed too. This accomodates an
atomic package removal commit, where \fBpackage.mask\fP entries and
files used only by the removed packages are removed. However, this can
cause trouble if the working copy is dirty.
sunrise-commit will check whether the removed package is not referenced
by any of the other packages by default. This is in order to ensure that
no package will be left with unsatisfied dependencies. However, if
you're removing the package because it was moved to a master repository
(e.g. gx86), you may want to pass \fB--force\fP in order to ignore that
check.
\fBsunrise-commit\fP will check whether any removed package is still
referenced by any of the other packages by default. If it finds an
internal package reference, it will give an error message. This is in
order to ensure that no package will be left with unsatisfied
dependencies. However, if you're removing the package because it was
moved to a master repository (e.g. gx86), you may use \fB--force\fP to
ignore that check.
.SH EXAMPLES
@ -177,7 +184,7 @@ $ cd app-foo/bar
$ sunrise-commit -t 'Fixing a broken Manifest.'
.fi
(\fB sunrise-commit\fP always updates the Manifest)
(\fBsunrise-commit\fP always updates the Manifest)
.I "4. Removing a package which was added to gx86:"