| |
@@ -1,3 +1,5 @@
|
| |
+ include::{partialsdir}/attributes.adoc[]
|
| |
+
|
| |
= Package Maintenance Guide
|
| |
:toc:
|
| |
|
| |
@@ -179,8 +181,9 @@
|
| |
Do remember not to leave stale sources lying around.
|
| |
|
| |
=== Switch to a different release branch
|
| |
+ [subs="attributes+"]
|
| |
....
|
| |
- fedpkg switch-branch <f34,el6,rawhide>
|
| |
+ fedpkg switch-branch <f{MAJOROSVER},el{MAJOREPELVER},rawhide>
|
| |
....
|
| |
|
| |
Each Fedora release has its own branch in each package repository
|
| |
@@ -319,9 +322,10 @@
|
| |
Each Fedora release is represented by a branch in the git repository.
|
| |
You can switch between them like this:
|
| |
|
| |
+ [subs="attributes+"]
|
| |
....
|
| |
- fedpkg switch-branch f34
|
| |
- fedpkg switch-branch f33
|
| |
+ fedpkg switch-branch f{MAJOROSVER}
|
| |
+ fedpkg switch-branch f{PREVIOUSOSVER}
|
| |
fedpkg switch-branch rawhide
|
| |
....
|
| |
|
| |
@@ -332,19 +336,20 @@
|
| |
However, git provides us with several handy tools for working with branches.
|
| |
Here's an example:
|
| |
|
| |
+ [subs="attributes+"]
|
| |
....
|
| |
fedpkg clone bzrtools
|
| |
# Make some changes in the rawhide branch
|
| |
fedpkg new-sources bzrtools-2.2.tar.gz
|
| |
gedit bzrtools.spec
|
| |
fedpkg commit
|
| |
- fedpkg switch-branch f34
|
| |
+ fedpkg switch-branch f{MAJOROSVER}
|
| |
git merge rawhide
|
| |
# for push into repo
|
| |
fedpkg push
|
| |
....
|
| |
|
| |
- This will _merge_ the changes from the `rawhide` branch to the `f34` branch.
|
| |
+ This will _merge_ the changes from the `rawhide` branch to the `f{MAJOROSVER}` branch.
|
| |
Git aficionados may note this is a somewhat unusual workflow,
|
| |
but it is appropriate to the context of package management.
|
| |
Remember,
|
| |
@@ -358,17 +363,18 @@
|
| |
so long as the branches have not previously diverged.
|
| |
That is, if you do this:
|
| |
|
| |
+ [subs="attributes+"]
|
| |
....
|
| |
fedpkg clone bzrtools
|
| |
# Make some changes in the rawhide branch
|
| |
fedpkg commit
|
| |
- fedpkg switch-branch f34
|
| |
- # Make some changes in the f34 branch
|
| |
+ fedpkg switch-branch f{MAJOROSVER}
|
| |
+ # Make some changes in the f{MAJOROSVER} branch
|
| |
fedpkg commit
|
| |
fedpkg switch-branch rawhide
|
| |
# Make some more changes in the rawhide branch
|
| |
fedpkg commit
|
| |
- fedpkg switch-branch f34
|
| |
+ fedpkg switch-branch f{MAJOROSVER}
|
| |
git merge rawhide
|
| |
....
|
| |
|
| |
@@ -520,7 +526,7 @@
|
| |
=== Making changes on an older branch without breaking the upgrade path
|
| |
|
| |
Here is the scenario:
|
| |
- You have built your package successfully on the `f34` branch,
|
| |
+ You have built your package successfully on the `f{MAJOROSVER}` branch,
|
| |
but there is a problem keeping your package from building on `last`.
|
| |
|
| |
Solution:
|
| |
In many places, a Fedora version number is used as and example,
in strings like Fedora 34, f34, fc34.
The docs read better if the version is always the current release,
or perhaps one behind.
AsciiDoc attributes are used to define
the current and previous OS version
as well as the current EPEL version
in one place.
The attributes are then referred to
in all examples that need those values.