Hello,
I would like to spin-off a package which is now a sub-package of another one.
Bacula contains 4mb of code and 40mb of docs; I would like to split them off:
[slaanesh@3zpc0560 bacula]$ ls -alghs *tar* 3,9M -rw-rw-r--. 1 slaanesh 3,9M 19 dic 09.16 bacula-5.2.3.tar.gz 40M -rw-rw-r--. 1 slaanesh 40M 19 dic 09.16 bacula-docs-5.2.3.tar.bz2
http://koji.fedoraproject.org/koji/buildinfo?buildID=279494
Everything is rebuilt every time there's the need to apply any change; while the docs are usually static for each release. With all the testing done for rawhide and the rebuilding of the same packages for RHEL 4/5/6 and Fedora 16 I lost a lot of time doing uploads for scratch builds and mock/koji rebuilds; so I would like to get away from this. Also RHEL 4 and 5 do not allow you to specify a separate BuildArch in a subpackage; which make "x86_64" pointless as an arch for a package containing PDF files.
bacula-docs does not really need to be part of the main package, and apart from good packaging, rpmlint checks and packaging guidelines what is needed to make a spinoff of the package in Fedora?
Following the same approach; after the docs I would also like to package "bacula-gui" which is not yet packaged in Fedora; but that count as a separate package. I have already prepared the separate packages on my laptop.
Thanks & happy new year to everybody. --Simone
On 01/02/2012 10:15 AM, Simone Caronni wrote:
bacula-docs does not really need to be part of the main package, and apart from good packaging, rpmlint checks and packaging guidelines what is needed to make a spinoff of the package in Fedora?
Just a review for bacula-docs as a new package.
~tom
== Fedora Project
On Mon, 2 Jan 2012 16:15:33 +0100 Simone Caronni negativo17@gmail.com wrote:
Everything is rebuilt every time there's the need to apply any change; while the docs are usually static for each release. With all the testing done for rawhide and the rebuilding of the same packages for RHEL 4/5/6 and Fedora 16 I lost a lot of time doing uploads for scratch builds and mock/koji rebuilds; so I would like to get away from this. Also RHEL 4 and 5 do not allow you to specify a separate BuildArch in a subpackage; which make "x86_64" pointless as an arch for a package containing PDF files.
Then why not just make a --without doc option (or a %global switch) in the spec file? Then the docs would be built by default, but you could also skip the building of the docs when you are just working on the package.
At least in the second option the sources for the -doc package need not be included in the srpm at all.
On Tue, Jan 03, 2012 at 09:49:19PM +0200, Jussi Lehtola wrote:
On Mon, 2 Jan 2012 16:15:33 +0100 Simone Caronni negativo17@gmail.com wrote:
Everything is rebuilt every time there's the need to apply any change; while the docs are usually static for each release. With all the testing done for rawhide and the rebuilding of the same packages for RHEL 4/5/6 and Fedora 16 I lost a lot of time doing uploads for scratch builds and mock/koji rebuilds; so I would like to get away from this. Also RHEL 4 and 5 do not allow you to specify a separate BuildArch in a subpackage; which make "x86_64" pointless as an arch for a package containing PDF files.
Then why not just make a --without doc option (or a %global switch) in the spec file? Then the docs would be built by default, but you could also skip the building of the docs when you are just working on the package.
The end user also has to download and install the new docs package everytime the main bacula package is updated when the -docs package is just a subpackage (instead of a separate package).
I agree that having a separate package makes a lot of sense here.
-Toshio
The end user also has to download and install the new docs package everytime the main bacula package is updated when the -docs package is just a subpackage (instead of a separate package).
I agree that having a separate package makes a lot of sense here.
-Toshio
That's the main reason for splitting. The only problem is that the document build system parses a header file in the Bacula source code to get the versions to put in the front page of the manuals.
It is acceptable to do the following during the %prep section?
%prep %setup -q
# To get the needed info for the fake header launch the following command in the bacula source folder: # cat src/version.h | grep ^#define
mkdir src cat > src/version.h << EOF #define VERSION "5.2.3" #define BDATE "16 December 2011" #define LSMDATE "16Dec11" #define PROG_COPYRIGHT "Copyright (C) %d-2011 Free Software Foundation Europe e.V.\n" #define BYEAR "2011" /* year for copyright messages in progs */ EOF
%build %configure --with-bacula=%{_builddir}/%{name}-%{version} make %{?_smp_mflags}
Those five lines from the src/version.h file are the only thing needed from the Bacula sources. By creating that file the sources compile fine. Is that ok?
Thanks, --Simone
On 01/05/2012 05:59 AM, Simone Caronni wrote:
The only problem is that the document build system parses a header file in the Bacula source code to get the versions to put in the front page of the manuals.
I think it might be simpler to add a bacula-devel package that includes the header files from the source code, then BuildRequires it for the -docs package.
~tom
== Fedora Project
Great idea!
I will do that.
Thanks, --Simone
On 5 January 2012 16:31, Tom Callaway tcallawa@redhat.com wrote:
On 01/05/2012 05:59 AM, Simone Caronni wrote:
The only problem is that the document build system parses a header file in the Bacula source code to get the versions to put in the front page of the manuals.
I think it might be simpler to add a bacula-devel package that includes the header files from the source code, then BuildRequires it for the -docs package.
~tom
== Fedora Project
packaging@lists.fedoraproject.org
-
Simone Caronni -
Susi Lehtola -
Tom Callaway -
Toshio Kuratomi