| Design of Samba Printing Packages | ||
|---|---|---|
| Prev | ||
The entire package will simply be a tar file that has been compressed by the GNU gzip program. Inside the compressed tar file, there will be all the files needed for the package as well as special file that controls how the files are installed.
Alternate file formats for the package were considered including the Red Hat RPM format, the Debian DEB format, and the Solaris pkg format. These formats are superior to a compressed tar file in terms of providing version control and the ability to easily uninstall the package. However, they fail the portability test since they are specific to a particular platform like the Solaris pkg format or they are available for other platforms like the Red Hat RPM format but not that prevalent on platforms other than Linux. Since Samba runs on many more platforms than just Linux, it makes sense to choose a format for the printer packages that can go anywhere that Samba can. Compressed tar files fit this goal well.
The package file will store the printer drivers for multiple Windows architectures including Windows NT and Windows 95/98.
In the order to direct the installation program, a control file called control will be present in the package's toplevel directory. The exact format of this control file is covered in the Control File section.
The final directory layout of the files in the package will not be reflected in the package file. However, all of the files for a particular architecture will be stored in a subdirectory of the package's toplevel directory corresponding to the architecture. Final placement of the files will actually happen when the package is installed by the installation program. The name of the subdirectory is based on the Windows architecture type as follows:
Table 1. Subdirectory Names
| Architecture | Directory Name |
|---|---|
| Windows 4.0 | WIN40 |
| Windows NT x86 | W32X86 |
| Windows NT R4000 | W32mips |
| Windows NT Alpha_AXP | W32alpha |
| Windows NT PowerPC | W32ppc |
If the any of the files were compressed using the Microsoft compress facility, then the files must be uncompressed before they will be stored in the appropriate subdirectory. No compressed files should be in the package at any time.
The files that should be stored in one of these subdirectories are the .INF file that the installer should read to install the printer driver and all files that the driver .INF file would need to install.
Here is a sample directory layout of a Samba printing package:
control
W32X86/
/* NT drivers */
WIN40/
/* Windows 9x drivers */ |
Since final placement of the files does not happen until installation time, some sort of information needs to be in the package to let the installation program know what to do. This control information will be stored in the package as a file called control. This file will be in the Microsoft .INF format.
All control files must contain a "common" section. The "common" section has several entries which describes general information about the package. The tag "name" contains the name of the package. The tag "version" contains the version of the package. The tag "display_name" is the name that should be displayed to users for this printer driver package in a GUI or other list presented to a user.
Then for each Windows architecture present in the package, there is a section describing that architecture for the installation program. The name of the section is the same as the subdirectory in which the files for that subdirectory are installed. Table 1 describes the subdirectory/section names in detail.
Each of these architecture sections must contain 3 tags. The first is the "inf_file" tag. The value of this tag is the name of the .INF file that the installation program will use to install the printer driver for this architecture. The .INF file in question must be stored in the architecture subdirectory. The name given for the "inf_file" tag should be relative to architecture's subdirectory in the package.
Giving the installation program the .INF file is not enough to identify how to install the printer driver since there could be potentially more than one printer described by an .INF file. Thus, the architecture section of the control file must also contain "manufacturer" and "model" tags to tell the installation program where to look in the driver .INF file.
The value of the "manufacturer" tag is the name of the tag in the [Manufacturer] section of the driver .INF file. The value of the "model" tag is the name of the model as found in the manufacturer section of the driver .INF file. With both pieces of information, the installation program can find the installation section of the driver .INF file and install the driver correctly on that architecture. Some .INF files may also describe more than one driver and providing the manufacturer and model in the control file allows the installer to isolate the correct parts of the.INF file.
Here is a sample control file:
[common] name=<string> version=<string> display_name=<string> [W32X86] inf_file=<filename> manufacturer=<string> model=<string> [WIN40] inf_file=<filename> manufacturer=<string> model=<string> |