Fink:Documentation Jottings:TypeField

From the Fink Wiki
Revision as of 01:57, 11 June 2007 by Dmacks (talk | contribs) (Reverted edit of LfyTdb, changed back to last version by Chris01)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


The 'Type:' field:



I found the information in the reference manual not so complete! Hence, I am writing this small write-up for new fink maintainers. I will give an example here and give some explanations.



I wanted to create a package called ccpnmr. It had three variants, namely, tk, opengl and mesa. It is also a python package. To allow for different versions of python in fink, I needed to create some more variants corresponding to different versions of python. I used a single Info2 format info file. Everything inside a Info2 file is exactly the same as in a regular info file, except for a few enhancements. The other main difference most will need to know is that the whole file is enclosed within a Info2: << ...Contents << tag. Eg.,
Info2: <<
Pacakge: foo
Version: 1.1.1
.....
<<

To create my variants, I defined my own 'type' called [handler].
My 'type' field looks like this:
Type: python (2.2 2.3 2.4), handler (tk opengl mesa)
This creates 3 times 3 different types of packages like mypackage-tk-py22, ...., mypackage-opengl-py24, etc. All this is done with just one info file.



The 'package' field looks like this:
Package: ccpnmr-%type_pkg[handler]-py%type_pkg[python]

There are two types of %type_ variables: %type_pkg and %type_raw. The difference is as follows:
Take the above example of Type: python (2.2 2.3 2.4).
%type_pkg[python] = 22
%type_pkg[python] = 23
%type_pkg[python] = 24
%type_pkg[] when expanded removes the dots.
%type_raw[python] = 2.2
%type_raw[python] = 2.3
%type_raw[python] = 2.4
%type_raw[] when expanded by fink, stil contains the dots, as raw as you enter!



Now if you look at the package field, you know why I wanted to use %type_pkg[python]. I wanted the names to end in -py24, etc. and not -py2.4, etc. We know that this is how a fink package should be named.

The newly created 'Type,' specific for my package 'handler,' has subtypes which are just strings. Hence, %type_pkg[handler] would be equivalent to %type_raw[handler].



The Depends/ BuildDepends field may contain dpendency packages specifc only for one or some of the variants. So to instruct fink that if the variant is 'foo' then the dependency would be 'bar,' we format the fields as follows: From the example above, Depends: python%type_pkg[python], python%type_pkg[python]-socket, x11, tcltk, (%type_pkg[handler] = opengl) freeglut-shlibs, (%type_pkg[handler] = mesa) mesa-shlibs

You can see from the above example that x11 and tcltk are listed as usual because they are needed by all the variants. The dependency needed by specific variants are written as '( %type_pkg[handler] = opengl) freeglut-shlibs,' etc. It would literally translate into the following: if the variant is of 'Type' [handler], opengl, then freeglut-shlibs is a dependency and not otherwise.