Difference between revisions of "Packages"
(Packages page - editing for clarity - Part 1 - break time.) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | [[Category:Admin Website]] | |
| − | + | [[Category:Programmer's Guide]] | |
| − | + | ||
| − | + | [[Image:AdvancedPackages.jpg|thumb|200px|Packages Advanced Admin Page]] | |
| − | + | ||
| − | + | '''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.''' | |
| − | + | ||
| − | + | =Overview= | |
| − | + | The purpose of the Packages page is to list all the software packages, and other files, that are needed by LinuxMCE so that they can be downloaded automatically using the ***ConfirmDependencies*** program. The Package definitions list all the places where that specific software can be downloaded from. ***Make Release*** will use the information in these Packages definitions to automatically compile software, and build archives, packages or other sources for download. | |
| − | + | ||
| + | =What is a package?= | ||
| + | A "package" is a collection of files that can contain software, documentation, configurations, images, audio files, video files, or any other type of file. A package can be either a Source package or a release package. Source packages usually contain source code, whereas release packages usually contain binaries (executables or libraries) created from the source code. | ||
| + | |||
| + | |||
| + | =What kind of Package?= | ||
| + | ==Source Package/Release Package/Reference Package?== | ||
| + | When creating or editing a package the first check box selects if this package contains source code, or release files. There are three primary kinds of package you can create: | ||
| + | ===Source Package=== | ||
| + | If you specify that it contains source code, that means the package must first be compiled to produce another package (the release package) that has the files for the end-user. .cpp, .h files and related, Makefile, .vcproj, etc., are examples of source code. Source Packages must have the manufacturer set to Pluto to be built or packaged by MakeRelease. | ||
| + | ===Release Package=== | ||
| + | Contains compiled binary versions of files that were defined in a Source Package. May contain documentation, configuration scripts or other ancillary files. Some 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. Release Packages must have the manufacturer set to Pluto to be created by MakeRelease. | ||
| + | ===Reference Package=== | ||
| + | Will refer to a package that exists in an external (non-LinuxMCE) repository. No files will be referenced and these packages will not be built by MakeRelease during a build cycle. | ||
| + | |||
| + | ==Linking a Source Package to a Release Package== | ||
| + | If the package you are editing is not source code, and source code is available, indicate on the next line what package contains the source code. The package must already have been defined to appear in the list of selectable packages. | ||
| + | |||
| + | ==How MakeRelease uses this information== | ||
| + | MakeRelease will first go through all packages that are source code, with Pluto as Manufacturer, and attempt to build them all. MakeRelease will build the source defined in the source code package and then create the release package from the resultant compiled binaries, and include any other files that are specified. MakeRelease will attempt to compile the source code for a given package before creating the Source Package, unless you specify the no build (-b) option. | ||
| + | |||
| + | =Package Type= | ||
| + | The Package type is for organizational purposes only and has no specific meaning. | ||
| + | |||
| + | =Manufacturer= | ||
| + | The Manufacturer should be Pluto IF the package should be compiled (or packaged) during a regular build cycle with MakeRelease. This should be empty for packages from non-LinuxMCE repositories. | ||
| + | |||
| + | =Package Compatibility= | ||
| + | Next you indicate what platforms this package is compatible with. | ||
| + | Whenever you see a compatibility pair listing an operating system and distro within the LinuxMCE webadmin it will always work like this: | ||
| + | *If you select an operating system only, it will match every distribution platform for that OS. | ||
| + | *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. | ||
| + | |||
| + | =Dependencies= | ||
| + | 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. | ||
| + | |||
| + | =Sources for Package= | ||
| + | Next specify the location 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. | ||
Latest revision as of 00:26, 22 January 2014
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.
Contents
Overview
The purpose of the Packages page is to list all the software packages, and other files, that are needed by LinuxMCE so that they can be downloaded automatically using the ***ConfirmDependencies*** program. The Package definitions list all the places where that specific software can be downloaded from. ***Make Release*** will use the information in these Packages definitions to automatically compile software, and build archives, packages or other sources for download.
What is a package?
A "package" is a collection of files that can contain software, documentation, configurations, images, audio files, video files, or any other type of file. A package can be either a Source package or a release package. Source packages usually contain source code, whereas release packages usually contain binaries (executables or libraries) created from the source code.
What kind of Package?
Source Package/Release Package/Reference Package?
When creating or editing a package the first check box selects if this package contains source code, or release files. There are three primary kinds of package you can create:
Source Package
If you specify that it contains source code, that means the package must first be compiled to produce another package (the release package) that has the files for the end-user. .cpp, .h files and related, Makefile, .vcproj, etc., are examples of source code. Source Packages must have the manufacturer set to Pluto to be built or packaged by MakeRelease.
Release Package
Contains compiled binary versions of files that were defined in a Source Package. May contain documentation, configuration scripts or other ancillary files. Some 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. Release Packages must have the manufacturer set to Pluto to be created by MakeRelease.
Reference Package
Will refer to a package that exists in an external (non-LinuxMCE) repository. No files will be referenced and these packages will not be built by MakeRelease during a build cycle.
Linking a Source Package to a Release Package
If the package you are editing is not source code, and source code is available, indicate on the next line what package contains the source code. The package must already have been defined to appear in the list of selectable packages.
How MakeRelease uses this information
MakeRelease will first go through all packages that are source code, with Pluto as Manufacturer, and attempt to build them all. MakeRelease will build the source defined in the source code package and then create the release package from the resultant compiled binaries, and include any other files that are specified. MakeRelease will attempt to compile the source code for a given package before creating the Source Package, unless you specify the no build (-b) option.
Package Type
The Package type is for organizational purposes only and has no specific meaning.
Manufacturer
The Manufacturer should be Pluto IF the package should be compiled (or packaged) during a regular build cycle with MakeRelease. This should be empty for packages from non-LinuxMCE repositories.
Package Compatibility
Next you indicate what platforms this package is compatible with. Whenever you see a compatibility pair listing an operating system and distro within the LinuxMCE webadmin it will always work like this:
- If you select an operating system only, it will match every distribution platform for that OS.
- 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.
Dependencies
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.
Sources for Package
Next specify the location 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.
