Packages
This page is not for the average user, so do not make any changes on this page unless you are prepared for the problems it may cause.
The purpose of this page is to list all the software and other files that are needed so that they can be downloaded automatically using the ***ConfirmDependencies*** program. This also lists all the places where the software can be downloaded from. ***Make Release*** is another program that will use the information on this page to automatically compile the software, and build archives, packages or other sources for download.
A "package" is a software program, or some other collection of files. The first check box indicates if this package contains source code, or other files. If you specify that it contains source code, then that means the package must first be compiled to produce another package that has the files for the end-user. .cpp, .h files and related, Makefile, .vcproj, etc., are examples of source code. Other types of files are more ambiguous, such as .php. While they are considered source code, they do not normally require compiling to be used and are generally not considered 'source code' for these purposes. If you use MakeRelease to do all the building, MakeRelease will first go through all the packages that are source code and attempt to build them all. If the package you are editing is not source code, and source code is available, you should indicate on the next line what package contains the source code. MakeRelease will attempt to compile the source code for a given package before outputting it, unless you specify the no build (-b) option.
The Package type is just for organizing packages.
The Manufacturer should be Pluto IF the package should be compiled during a regular build-maindebs cycle. For all package definition, that just reference external deb files for dependency sake, this should be left empty.
Next you indicate what platforms this package is compatible with. Whenever you see a compatibility pair listing an operating system and distro it always works like this: If you select an operating system only, it will match every distribution platform for that platform. If you select a distribution, regardless of the operating system you chose, only that particular distribution is a match. If you leave both of them at 'any', then it will match every platform.
Next, indicate what packages this one depends on--its dependencies. The dependencies will always be installed first. If a package is only required to build from source code, then that package should be a dependent of the source code only. For example, our DCE Library requires MySql. So the DCE library depends on MySql. The MySql development libraries are required to build DCE from source code, so the DCE Library Source Code package depends on MySql development libraries. They will only be installed then if the user wants to build from source. If you add a dependent package and that dependent package is not compatible with the given platform, it will be ignored. For example, the LinuxMCE Orbiter requires ALSA libraries when running on Linux. So, the Orbiter package is marked as compatible with all operating systems. It depends on ALSA, which is only compatible with Linux. When the Orbiter is installed on Windows, it will ignore the ALSA dependency.
Next specify the source of the package--where to get it from. The Repository Sources are maintained in a separate table. The values in for Name, Repository, Version and Parms are specific to the type of repository, and how the installer will use them. For archives, like .tar files, the installer will look up the URL from the Repository source, and assume the "Repository" field is a directory on that source, and the name of the file is "Name"[_"Version"]"Parms". If Name is "myfile", Version is "2.0" and Parms is ".zip", it will try to download a file myfile_2.0.zip. For Ubuntu archives, Name is the package name, Version is the Version number, and Parms is not used. If you will be creating your own installer to handle a given repository type you have some flexibility in defining how these fields are used so that it is appropriate for the given type. Add compatibility for the repository sources so the system knows what platforms this source can be used on.
Lastly you must specify the directories and files that will go into the package. For each type of directory/file add a new directory. You can add multiple directories of the same type, and make multiple directory types point to the same place. The path is assumed to be the destination on the user's machine. There are build modules that are specific to each repository source and will interpret the path. Generally, on the Linux systems the path is considered relative to /usr while on Windows machines it is relative to \Program Files. If you want different behavior for different operating systems or distros, just create more directories and specify that the files are only compatible with the given distro/os. If the path starts with a /, it is considered absolute, otherwise relative.
When MakeRelease runs, it takes as a parameter 2 prefixes to find the files: source prefix, and non-source prefix. When searching for the input files it will prepend the path with the source prefix if the type of directory is "Source Implementation", or with the non-source path for all other types. If you check 'Flip Source' then this behavior is reversed. If you type in a command in the text box, then that command will be executed from the input path before attempting to copy the file. This allows for commands such as make, copy, etc.
If the type of directory is Source Implementation, it will first do a search and replace on all the .cpp, .c and .h files replacing any occurancies of <=version=> with the actual version it is compiling.
The compiled output directory contains files that need to be compiled, but should not be output in the package. This directory is used only compiling. For example, the source code package may contain entries in Compiled Directory for all the files it should build, which the non-source code package will later use. Those files in the Compiled Directory will have the make command. You could alternatively put the make command in the non-source package. But in that case the command would get executed every time the package was built, whether build/compile was enabled or disabled. So, in summary, if a non-source package needs a command to be run to create a file every time the package is built, put that command in the file's make command. If the command should only be run when doing a clean build from source, put it in the Compiled Directory of the source package.
