Solaris/FOSS specfiles example1: Difference between revisions

From KDE Community Wiki
(documented FOSS spec file with conditional variables and full plist)
 
 
(7 intermediate revisions by 4 users not shown)
Line 6: Line 6:
project, there are several hundred spec files and easily double that
project, there are several hundred spec files and easily double that
in support files (once all the DUDE tarfile conversions are completed)
in support files (once all the DUDE tarfile conversions are completed)
so trying to go back a rev can be rather painful  This wiki attempts
so trying to go back a rev can be rather painful. This wiki attempts
to clearly document the ease in which this can be handled.
to clearly document the ease in which this can be handled.


Line 13: Line 13:
: explicit plists are used to catch differences between package revisions
: explicit plists are used to catch differences between package revisions
: every decision should be based on a simple true/false decision.
: every decision should be based on a simple true/false decision.
: we don't want to maintain too many revisions internally to the spec, just enough to go back easily if something breaks, so current, and last working (or 2) is really all we want to support.  Otherwise, you have to be something of a mercurial guru to figure out how to get back the last working version.


'''Header, self explanatory'''
'''Header, self explanatory'''
<code>
<syntaxhighlight lang="text">
# SPEC file for expat library.
# SPEC file for expat library.
#
#
Line 27: Line 29:
#
#
# Expat is a GNU library for xml parsing
# Expat is a GNU library for xml parsing
</code>
</syntaxhighlight>


'''Package definition'''
'''Package definition'''
Line 33: Line 35:
src_ver is the variable that defines the package source version
src_ver is the variable that defines the package source version


<code>
<syntaxhighlight lang="text">
#
#
# Support expat-2.0.0 and 2.0.1. 2.0.1 now default.
# Support expat-2.0.0 and 2.0.1. 2.0.1 now default.
Line 56: Line 58:
handlers for things the parser might find in the XML
handlers for things the parser might find in the XML
document (like start tags).
document (like start tags).
</code>
</syntaxhighlight>


'''versioning conditional defines'''
'''versioning conditional defines'''


<code>
<syntaxhighlight lang="text">
%define is_ver_2_0_0    %( test %{src_ver} = "2.0.0" && echo 1 || echo 0)
%define is_ver_2_0_0    %( test %{src_ver} = "2.0.0" && echo 1 || echo 0)
%define is_ver_2_0_1    %( test %{src_ver} = "2.0.1" && echo 1 || echo 0)
%define is_ver_2_0_1    %( test %{src_ver} = "2.0.1" && echo 1 || echo 0)
</code>
</syntaxhighlight>


during development, it's possible that we could iterate through
during development, it's possible that we could iterate through
several versions.  In the case where we need to test a package
several versions.  These versions will likely be important to the
base-<module>.spec file, since the intention is to keep patches
as history, and use the '''version''' test to manage them. Again,
we really ought to keep no more than 1 working, and 2 previous
versions, otherwise the clutter will become a bit difficult to
deal with.
 
On a project like KDE4 on Solaris, there are so many working parts,
being about to back rev a module quickly has really been useful.
 
In the case where we need to test a package
minor rev greater than, equal to 1, we can do the following:
minor rev greater than, equal to 1, we can do the following:


<code>
<syntaxhighlight lang="text">
%define expat_minor_rev      %( echo %{src_ver} | cut -f3 -d\. )
%define expat_minor_rev      %( echo %{src_ver} | cut -f3 -d\. )
%define expat_rev_ge_2_0_1  %( test ${expat_minor_rev} -ge 1 && echo 1 || echo 0)
%define expat_rev_ge_2_0_1  %( test ${expat_minor_rev} -ge 1 && echo 1 || echo 0)
</code>
</syntaxhighlight>


'''collection of standard includes use for the KDE4 project'''
'''collection of standard includes use for the KDE4 project'''
<code>
<syntaxhighlight lang="text">
%include foss-paths.inc


%include base-foss-header.inc
%include base-foss-header.inc
%include foss-paths.inc


%include foss-common32.inc
%include foss-common32.inc
Line 88: Line 100:


%include base-foss-common.inc
%include base-foss-common.inc
</code>
</syntaxhighlight>
 
the base-expat.spec is used for both 32-bit and 64-bit building, and on occasion, you'll find that some package didn't honor the .../lib/{amd64|sparcv9} construct, and you'll use the %install area to manually clean that up.


'''Explicit plist'''
'''Explicit plist'''
<syntaxhighlight lang="text">
%files
%files
%dir %attr (0755, root, sys) /opt
%dir %attr (0755, root, sys) /opt
Line 101: Line 116:
%{_libdir}/libexpat.so
%{_libdir}/libexpat.so
%{_libdir}/libexpat.so.1
%{_libdir}/libexpat.so.1
</code>
</syntaxhighlight>


'''How to use versions with explicit plists'''
'''How to use versions with explicit plists'''


Why use an explicit plist? As another example,
Why use an explicit plist? As another example,ncurses-5.6. For
ncurses-5.6. for 18 months, the plist was in
18 months, the plist was in place, explicitly defined. During
place, explicitly defined. During the change
the change to full spec, a minor change occured, rather
to full spec, a minor change occured, rather
unintentionally, and another set of libraries built which would
unintentionally, and another set of libraries
have never been identified had a global plist been used.
built which would have never been identified
had a global plist been used.


Here, even a minor revision of the package generated
Here, even a minor revision of the package generated
Line 118: Line 131:


For a file such as an include file, we might use
For a file such as an include file, we might use
a ''%if %{expat_minor_rev_ge_201}''
a '''''%if %{expat_minor_ge_2_0_1}''''' construct instead.
 
This model works good for the FOSS packages, but for
the KDE4 modules, we've agreed that the library versioning
will cause probably more churn in the spec files than is
gained by having explicit versioning for those.


<code>
<syntaxhighlight lang="text">
%if %{is_ver_2_0_0}
%if %{is_ver_2_0_0}
%{_libdir}/libexpat.so.1.5.0
%{_libdir}/libexpat.so.1.5.0
%endif
%endif
%if %{is_ver_2_0_1}
%if %{is_ver_2_0_1}
%{_libdir}/libexpat.so.1.5.2
%{_libdir}/libexpat.so.1.5.2
%endif
%endif
</code>
</syntaxhighlight>


'''Explicit plist continued....'''
'''Explicit plist continued....'''


<code>
<syntaxhighlight lang="text">
%dir %attr (0755, root, bin) %{_includedir}
%dir %attr (0755, root, bin) %{_includedir}
%{_includedir}/expat.h
%{_includedir}/expat.h
Line 158: Line 177:
%changelog
%changelog
* Tue Dec  1 2009 - [email protected]
* Tue Dec  1 2009 - [email protected]
- convert to full spec (No DUDE files), explicit plist
- convrt to spec, add explicit plist
- add upgrade to version 2.0.1
- add upgrade to version 2.0.1
* Wed Oct  1 2008 - [email protected]
* Wed Oct  1 2008 - [email protected]
Line 164: Line 183:
* Thu Jan 17 2008 - [email protected]
* Thu Jan 17 2008 - [email protected]
- Initial version
- Initial version
</code>
</syntaxhighlight>

Latest revision as of 19:17, 18 March 2016

Writing conditional Spec files

In general, the reason for writing a conditional spec file is so that you don't have to rely on a CMS system to figure out which version of a module you want to check out. Like tke KDE4 on Solaris project, there are several hundred spec files and easily double that in support files (once all the DUDE tarfile conversions are completed) so trying to go back a rev can be rather painful. This wiki attempts to clearly document the ease in which this can be handled.

Philosophy

FOSS spec files care about src_ver or version
explicit plists are used to catch differences between package revisions
every decision should be based on a simple true/false decision.
we don't want to maintain too many revisions internally to the spec, just enough to go back easily if something breaks, so current, and last working (or 2) is really all we want to support. Otherwise, you have to be something of a mercurial guru to figure out how to get back the last working version.

Header, self explanatory

# SPEC file for expat library.
#
# Copyright 2009 Ben Taylor
# Copyright 2008 Lukas Oboril
# Copyright 2008 Adriaan de Groot
# Copyright 2008 Stefan Teleman
#
# This file is released under the terms of an MIT / 1-clause BSD
# license. See the file LICENSE.MIT for details.
#
# Expat is a GNU library for xml parsing

Package definition

src_ver is the variable that defines the package source version

#
# Support expat-2.0.0 and 2.0.1. 2.0.1 now default.
#
%define src_name        expat
#%define src_ver                2.0.0
%define src_ver         2.0.1
Name:                   %{src_name}
Version:                %{src_ver}
SUNW_Pkg:               FOSS%{name}
%define src_rev         2

Summary:                XML parser library
License:                MIT
Source:                 %{site_sourceforge}/expat/%{src_name}-%{src_ver}.tar.gz
Url:                    http://expat.sf.net/
Group:                  System/Libraries

%description
Expat is an XML parser library written in C. It is a
stream-oriented parser in which an application registers
handlers for things the parser might find in the XML
document (like start tags).

versioning conditional defines

%define is_ver_2_0_0    %( test %{src_ver} = "2.0.0" && echo 1 || echo 0)
%define is_ver_2_0_1    %( test %{src_ver} = "2.0.1" && echo 1 || echo 0)

during development, it's possible that we could iterate through several versions. These versions will likely be important to the base-<module>.spec file, since the intention is to keep patches as history, and use the version test to manage them. Again, we really ought to keep no more than 1 working, and 2 previous versions, otherwise the clutter will become a bit difficult to deal with.

On a project like KDE4 on Solaris, there are so many working parts, being about to back rev a module quickly has really been useful.

In the case where we need to test a package minor rev greater than, equal to 1, we can do the following:

%define expat_minor_rev      %( echo %{src_ver} | cut -f3 -d\. )
%define expat_rev_ge_2_0_1   %( test ${expat_minor_rev} -ge 1 && echo 1 || echo 0)

collection of standard includes use for the KDE4 project

%include base-foss-header.inc
%include foss-paths.inc

%include foss-common32.inc
%use base32 = base-expat.spec
%if %has64
%include foss-common64.inc
%use base64 = base-expat.spec
%endif

%include base-foss-common.inc

the base-expat.spec is used for both 32-bit and 64-bit building, and on occasion, you'll find that some package didn't honor the .../lib/{amd64|sparcv9} construct, and you'll use the %install area to manually clean that up.

Explicit plist

%files
%dir %attr (0755, root, sys) /opt
%dir %attr (0755, root, sys) %{_prefix}
%defattr (-, root, bin)
%dir %attr (0755, root, bin) %{_bindir}
%{_bindir}/xmlwf

%dir %attr (0755, root, bin) %{_libdir}
%{_libdir}/libexpat.so
%{_libdir}/libexpat.so.1

How to use versions with explicit plists

Why use an explicit plist? As another example,ncurses-5.6. For 18 months, the plist was in place, explicitly defined. During the change to full spec, a minor change occured, rather unintentionally, and another set of libraries built which would have never been identified had a global plist been used.

Here, even a minor revision of the package generated a new minor revision of the shared library. Here we would use an explicit version test.

For a file such as an include file, we might use a %if %{expat_minor_ge_2_0_1} construct instead.

This model works good for the FOSS packages, but for the KDE4 modules, we've agreed that the library versioning will cause probably more churn in the spec files than is gained by having explicit versioning for those.

%if %{is_ver_2_0_0}
%{_libdir}/libexpat.so.1.5.0
%endif

%if %{is_ver_2_0_1}
%{_libdir}/libexpat.so.1.5.2
%endif

Explicit plist continued....

%dir %attr (0755, root, bin) %{_includedir}
%{_includedir}/expat.h
%{_includedir}/expat_external.h

%dir %attr (0755, root, sys) %{_datadir}
%dir %attr (0755, root, bin) %{_mandir}
%{_mandir}/man1/xmlwf.1

%if %{has64}
%dir %attr (0755, root, bin) %{_bindir}/%{_arch64}
%{_bindir}/%{_arch64}/xmlwf

%dir %attr (0755, root, bin) %{_libdir}/%{_arch64}
%{_libdir}/%{_arch64}/libexpat.so
%{_libdir}/%{_arch64}/libexpat.so.1
%if %{is_ver_2_0_0}
%{_libdir}/%{_arch64}/libexpat.so.1.5.0
%endif
%if %{is_ver_2_0_1}
%{_libdir}/%{_arch64}/libexpat.so.1.5.2
%endif

%endif

%changelog
* Tue Dec  1 2009 - [email protected]
- convrt to spec, add explicit plist
- add upgrade to version 2.0.1
* Wed Oct  1 2008 - [email protected]
- Turned back into a spec file
* Thu Jan 17 2008 - [email protected]
- Initial version