all the rationale on splitting is written in the first post of the bug
I'm pasting it here for reference.
The main reason is of course avoiding building and updating 40+ mb of docs
that should change only once a year instead of every update.
This is a spinoff of the bacula-docs subpackage that is present inside bacula
that I'm currently co-mantaining:
Motivations for the spin-off:
- To avoid rebuilding 40 mb of docs each release that never change and to avoid
uploading 40 mb for each koji scratch build.
- It is pointless to have the user update all the docs each time we generate a
new bacula package because of a security fix or bug.
- It is also built for RHEL 4/5/6 (most of the userbase goes there), and in
RHEL 4/5 there's no way to specify a different BuildArch in a subpackage, so
i.e. on RHEL 5 you got "x86_64" pdf files.
- The package bacula-gui (currently not available in Fedora) will follow the
same approach and be a separate Review Request.
- It has the release number immediately after the one which is in rawhide so it
will update the one generated from the bacula package. If it's accepted I will
remove the docs in the bacula package.
- It passes all rpmlint checks.
- It doesn't have an install section, all documents are included as %docs from
the source folder where they are generated.
On 11 January 2012 10:37, Ralf Corsepius <rc040203(a)freenet.de> wrote:
On 01/11/2012 10:20 AM, Matthias Runge wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> On 10/01/12 12:10, Simone Caronni wrote:
> I just stumbled upon this:
> the plan is to separate the bacula-docs subpackage from bacula package
> and create a new package bacula-docs.
> (review request at
> My question is, is the split possible in existing trees, e.g in F16?
When carefully done, yes. The minimum requirement would be such a change
to be "100% transparent to users within a Fedora release".
IMO, however, the better question would be "why to split out docs?".
In general, separate doc packages make sense in cases they are "very
large" or in case the docs are "mostly irrelevant" to users (i.e. hardly
anybody will want to read/install them).
In all other cases separate doc packages do not add many benefits but only
add packaging complexity (esp. dependencies) and add sources of potential
I am not familiar with your package to be able to comment on your
packaging mailing list
You cannot discover new oceans unless you have the courage to lose sight of
the shore (R. W. Emerson).