Clarified the EXTENDED DESCRIPTION section of the manpage and enforced more consistent highlighting of ``sunrise-commit''.
This commit is contained in:
parent
dbd11bc848
commit
f8ea18212e
@ -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:"
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user