-
Notifications
You must be signed in to change notification settings - Fork 24
Development and Features
Table of Contents generated with DocToc
- Build scripts
- Development Cycle
- LibreGeek Repository information
- Libregeek Repository cycle
- Script Routines
- Functions
- Repository structure
- Planned Features / TO-DO List
- Requesting Features
- Contributing
- Backporting packages
- Debian packaging help and links:
- Creating packages
#Table of contents
- Build scripts
- Development Cycle
- LibreGeek Repository information
- How it all works
- Functions
- Repository structure
- Planned Features / TO-DO List
- Requesting Features
- Contributing
Builds scripts are now located at https://github.com/ProfessorKaos64/LibreGeek-Packaging
Generally speaking "unstable" release marks are odd numbers, "stable" release marks are well...stable. The master branch is considered the most stable, but beta versions that feel "comfortable" can have these version numbers too. Sometimes, an "rc", aka a "release candidate" may show up, where I feel things are fairly good, but still need some verification.
Version notation:
[0.0.0], denoting [milestone.subrelease.fixes]
Packages from repositories that do not specify versions
[0.YYYYMMDD], 0, followed by the current date. The change log should reflect the latest commit. This is done this way so that, if upstream releases and actual version, it will generally supersede the 0.
In the beginning, builds for packaging were done on host systems with dpkg-buildpackage
, along with standard debian structured files required for packaging .deb packages. Currently, the approach is vastly different, with clean-room building being done via pbuilder.
When a VPS is spun up by myself, I fire off the configure-packaging-env.sh setup script. This installs a few basic packages, configures github information, config files (such as .bashrc), and pbuilder. Packages are built using build scripts at LibreGeek-Packaging. These packages are either built to a testing repository, or the stable repository. Once a packaging cycle is complete, packages are processed with reprepro and synced the the packages.libregeek.org repository.
If you are interested in contributing build scripts or maintaining them, please use the contact form at libregeek and choose the subject "LibreGeek development." If you wish to follow existing conventions of build scripts and more, see the templates folder. The key file would be build-script.template. Do note that the aim is not to duplicate efforts from Debian if a package exists (due to SteamOS being currently built atop Debian Jessie). However, packages should be rebuilt from source code if they hail from other distros, or require newer versions not found in that release of Debian.
Please see the SteamOS Tools Repository wiki page.
This section notes how this repository is setup to give you a better idea of where objects come from, how to improve upon them, and make suggestions, corrections, or report issues.
This script used to be the focal point of the repository, running scripted routines to install software that required multiple commands, provide validation for packages, management, and more. Once Debian packaging was solidified, many of these areas are underused, or not used at all. One such exception is "web apps", due to a user-facing menu being utilized, and the desire not to maintain the fast moving Chrome browser as a package. However, it is still used, and should be noted as a piece of the repository.
Below is a general account of the flow the script.
- User requests a software type to be installed
- A warning screen is shown, which also doubles to check, and add upon request, the needed Debian sources.
- The script checks for arguments, and also determines if we are dealing with a custom software list, over pre-made types.
- script modules are sourced via a common import function
- The main function runs, importing the modules based on the path to the module within
scriptmodules/
- The software type function runs, assigning specific software lists and/or running a specific script for the given type.
- Software types are checked for which action they should be performing, may it be uninstall, list packages, check packages, or install.
- The software function then runs on types that requested it, setting the correct mode, and apt-cache directory. Each item in the software list is ran through a for-loop to install the package. Some basic checks account for failure.
- Supplemental scripts are hooked into the requested software type, if needed.
- Packages are cleaned up for those that are not needed any more.
- Function names follow (or try to) the location or purpose they serve. For example, script modules are prefixed with the acronym they follow, such as
rpc_configure_common
that lives withscriptmodules/retroarch-post-cfgs.shinc
This section describes what each directory is on a general level.
- Main directory - desktop-software.sh script, add-debian-repos.sh script, authors file, readme file, contributing guide, and the repo disclaimer.
- Artwork - SteamOS BPM banners and various images.
- cfgs - Configuration files for desktop shortcuts, gamepads, init scripts, retroarch, software lists, web apps, and other various software.
- docs - External installation guides.
- ext-game-istallers - installer scripts and files for games outside of Steam, or modification of those within it.
- extra - scripts not intended for general users, such as uploading built packages to libregeek.org
- scriptmodules - pluggable script modules for use with desktop-software.sh only. This allows all scripts called by desktop-software (as well as sub-scripts) to utilize functions at any time.
- Supplemental - This directory is not used for much, and may be consolidated into the "extra" directory, or vice-versa. Currently only holds some libraries for Widevine support under Chromium.
- Utilities - Various tools to supplement desktop-software.sh script types or facilitate other duties, such as building packages, test environments, automation scripts, and more.
Please also consider helping out with any open issues.
- A lot of code cleanup for bash code
- Cleanup of wiki entries, expansion of existing entries
- Playing Steam (Windows) Games Using Crossover Linux
- Playing Steam (Windows) Games Using Lutris
- Figure out a method to use obs-studio in SteamOS BPM.
- Display rate tool for Steam session (steamcompmgr)? Possibly some sort of
xrandr --output DVI-I-1 --mode 1920x1080 --rate 144
script
Please understand that working in new features takes time.
Please take time to read the Testing checklist, as well as this helpful guide.
Backporting a newer Debian package is not out of the questin. Here is an example for mame, detailed in the Debain wiki. release available in sid/experimental. If the package you're looking for not available in Sid, but in a Ubuntu PPA, you can have a look at CreatePackageFromPPA.
See "Creating Packages" for more information.
There are available build scripts for building from src, PPA, or by using a template.
- Templates
- build-deb-from-ppa.sh
- build-deb-from-src.sh
If you are contributing code, and merging upstream commits against your own, a useful practice is to setup a 'mergetool' like kdiff3. For more, please see the gitguys tutorial.