geos_one/go-utils
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Nathan Phillip Brink 2010-10-30 16:34:32 -04:00
parent dbd11bc848
commit f8ea18212e
1 changed files with 38 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

69
sunrise-commit.1.in
View File

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