Packages - Revision history

Phenigma: Packages page - editing for clarity - Part 1 - break time.

2014-01-21T23:26:03Z

Packages page - editing for clarity - Part 1 - break time.

←Older revision		Revision as of 23:26, 21 January 2014
Line 6:		Line 6:
	'''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.'''		'''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.		=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.

	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~~.		=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.

	~~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~~.		=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.

	~~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~~.		==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.		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.		=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.		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.

Marie.o: Added note on the manufacturer field for the package definition.

2010-01-14T07:36:03Z

Added note on the manufacturer field for the package definition.

←Older revision		Revision as of 07:36, 14 January 2010
Line 11:		Line 11:

	The Package type is just for organizing packages.		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 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.

Rwilson131: Added Screenshots

2007-11-10T15:02:12Z

Added Screenshots

←Older revision		Revision as of 15:02, 10 November 2007
Line 1:		Line 1:
	~~<p>~~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.~~</p>~~		[[Category:Admin Website]]
	~~<p>~~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.~~</p>~~		[[Category:Programmer's Guide]]
	~~<p>~~The Package type is just for organizing packages.~~</p>~~
	~~<p>~~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.~~</p>~~		[[Image:AdvancedPackages.jpg\|thumb\|200px\|Packages Advanced Admin Page]]
	~~<p>~~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.~~</p>~~
	~~<p>~~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.~~</p>~~		'''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.'''
	~~<p>~~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.~~</p>~~
	~~<p>~~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.~~</p>~~		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.
	~~<p>~~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.~~</p>~~
	~~<p>~~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.~~</p>~~		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.

			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.

Juliet at 09:22, 19 March 2007

2007-03-19T09:22:42Z

←Older revision		Revision as of 09:22, 19 March 2007
Line 1:		Line 1:
	<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table><p>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.</p>		<p>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.</p>
	<p>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.</p>		<p>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.</p>
	<p>The Package type is just for organizing packages.</p>		<p>The Package type is just for organizing packages.</p>

Juliet at 12:49, 15 March 2007

2007-03-15T12:49:14Z

←Older revision		Revision as of 12:49, 15 March 2007
Line 1:		Line 1:
	<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table><p>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.</p>		<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table><p>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.</p>
	<p>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 ~~outputing~~ it, unless you specify the no build (-b) option.</p>		<p>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.</p>
	<p>The Package type is just for organizing packages.</p>		<p>The Package type is just for organizing packages.</p>
	<p>Next you indicate what platforms ~~the~~ 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.</p>		<p>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.</p>
	<p>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 ~~Pluto~~ 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.</p>		<p>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.</p>
	<p>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 ~~Respository~~ 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 ~~Debian~~ 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.</p>		<p>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.</p>
	<p>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 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.</p>		<p>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.</p>
	<p>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 ~~attemping~~ to copy the file. This allows for commands such as make, copy, etc.</p>		<p>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.</p>
	<p>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 ~~occurances~~ of <=version=> with the actual version it is compiling.</p>		<p>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.</p>
	<p>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.</p>		<p>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.</p>

Wikiadmin: Imported document

2006-06-05T16:43:54Z

Imported document

New page

<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007. In general any information should apply to LinuxMCE. However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table>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 outputing it, unless you specify the no build (-b) option.
The Package type is just for organizing packages.
Next you indicate what platforms the 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 Pluto 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 Respository 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 Debian 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 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 attemping 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 occurances 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.