Categories
Cloud DevOps DevSecOps-Security-Privacy Linux Software Engineering

DevOps toolchain

See also: CloudOps, toolchain

“A DevOps toolchain is a set or combination of tools that aid in the delivery, development, and management of software applications throughout the systems development life cycle, as coordinated by an organization that uses DevOps practices.

Generally, DevOps tools fit into one or more activities, which supports specific DevOps initiatives: Plan, Create, Verify, Package, Release, Configure, Monitor, and Version Control.[1][2]” (WP)

Toolchains

“In software, a toolchain is the set of programming tools that is used to perform a complex software development task or to create a software product, which is typically another computer program or a set of related programs. In general, the tools forming a toolchain are executed consecutively so the output or resulting environment state of each tool becomes the input or starting environment for the next one, but the term is also used when referring to a set of related tools that are not necessarily executed consecutively.[3][4][5]

As DevOps is a set of practices that emphasizes the collaboration and communication of both software developers and other information technology (IT) professionals, while automating the process of software delivery and infrastructure changes, its implementation can include the definition of the series of tools used at various stages of the lifecycle; because DevOps is a cultural shift and collaboration between development and operations, there is no one product that can be considered a single DevOps tool. Instead a collection of tools, potentially from a variety of vendors, are used in one or more stages of the lifecycle.[6][7]” (WP)

Stages of DevOps

Further information: DevOps

Plan

Plan is composed of two things: “define” and “plan”.[8] This activity refers to the business value and application requirements. Specifically “Plan” activities include:

  • Production metrics, objects and feedback
  • Requirements
  • Business metrics
  • Update release metrics
  • Release plan, timing and business case
  • Security policy and requirement

A combination of the IT personnel will be involved in these activities: business application owners, software developmentsoftware architects, continual release management, security officers and the organization responsible for managing the production of IT infrastructure.

Create

Create is composed of the building (see also build automation), coding, and configuring of the software development process.[8] The specific activities are:

Tools and vendors in this category often overlap with other categories. Because DevOps is about breaking down silos, this is reflective in the activities and product solutions.[clarification needed]

Verify

Verify is directly associated with ensuring the quality of the software release; activities designed to ensure code quality is maintained and the highest quality is deployed to production.[8] The main activities in this are:

Solutions for verify related activities generally fall under four main categories: Test automation , Static analysis , Test Lab, and Security.

Packaging

Packaging refers to the activities involved once the release is ready for deployment, often also referred to as staging or Preproduction / “preprod”.[8] This often includes tasks and activities such as:

  • Approval/preapprovals
  • Package configuration
  • Triggered releases
  • Release staging and holding

Release

Release related activities include schedule, orchestration, provisioning and deploying software into production and targeted environment.[9] The specific Release activities include:

  • Release coordination
  • Deploying and promoting applications
  • Fallbacks and recovery
  • Scheduled/timed releases

Solutions that cover this aspect of the toolchain include application release automation, deployment automation and release management.

Configure

Configure activities fall under the operation side of DevOps. Once software is deployed, there may be additional IT infrastructure provisioning and configuration activities required.[8] Specific activities including:

  • Infrastructure storage, database and network provisioning and configuring
  • Application provision and configuration.

The main types of solutions that facilitate these activities are continuous configuration automationconfiguration management, and infrastructure as code tools.[10]

Monitor

Monitoring is an important link in a DevOps toolchain. It allows IT organization to identify specific issues of specific releases and to understand the impact on end-users.[8] A summary of Monitor related activities are:

  • Performance of IT infrastructure
  • End-user response and experience
  • Production metrics and statistics

Information from monitoring activities often impacts Plan activities required for changes and for new release cycles.

Version Control

Version Control is an important link in a DevOps toolchain and a component of software configuration management. Version Control is the management of changes to documents, computer programs, large web sites, and other collections of information.[8] A summary of Version Control related activities are:

  • Non-linear development
  • Distributed development
  • Compatibility with existent systems and protocols
  • Toolkit-based design

Information from Version Control often supports Release activities required for changes and for new release cycles.

See also

References

  1. ^ Edwards, Damon. “Integrating DevOps tools into a Service Delivery Platform”dev2ops.org.
  2. ^ Seroter, Richard. “Exploring the ENTIRE DevOps Toolchain for (Cloud) Teams”infoq.com.
  3. ^ “Toolchain Overview”nongnu.org. 2012-01-03. Retrieved 2013-10-21.
  4. ^ “Toolchains”elinux.org. 2013-09-08. Retrieved 2013-10-21.
  5. ^ Imran, Saed; Buchheit, Martin; Hollunder, Bernhard; Schreier, Ulf (2015-10-29). Tool Chains in Agile ALM Environments: A Short IntroductionLecture Notes in Computer Science9416. pp. 371–380. doi:10.1007/978-3-319-26138-6_40ISBN 978-3-319-26137-9.
  6. ^ Loukides, Mike (2012-06-07). “What is DevOps?”.
  7. ^ Garner Market Trends: DevOps – Not a Market, but Tool-Centric Philosophy That supports a Continuous Delivery Value Chain (Report). Gartner. 18 February 2015.
  8. a b c d e f g Avoid Failure by Developing a Toolchain that Enables DevOps (Report). Gartner. 16 March 2016.
  9. ^ Best Practices in Change, Configuration and Release Management (Report). Gartner. 14 July 2010.
  10. ^ Roger S. Pressman (2009). Software Engineering: A Practitioner’s Approach (7th International ed.). New York: McGraw-Hill.

Categories

Sources:

Fair Use Sources:

Categories
JavaScript Software Engineering

Deno Runtime for JavaScript and TypeScript

See also: JavaScript, JavaScript Bibliography and Bibliography of JavaScript Libraries and Web Frameworks

Deno.svg
Original author(s)Ryan Dahl
Developer(s)Various
Initial releaseMay 13, 2018; 2 years ago[1]
Stable release1.8.0[2]  / 2 March 2021; 3 days ago
Repositorygithub.com/denoland/deno
Written inTypeScriptJavaScriptRustC++(V8 bindings)
Operating systemLinuxmacOSMicrosoft Windows
TypeRuntime environment
LicenseMIT License[3][4]
Websitedeno.land 

Deno is a runtime for JavaScript and TypeScript that is based on the V8 JavaScript engine and the Rust programming language. It was created by Ryan Dahl, original creator of Node.js, and is focused on productivity.[5] It was announced by Dahl in 2018 during his talk “10 Things I Regret About Node.js”.[6] Deno explicitly takes on the role of both runtime and package manager within a single executable, rather than requiring a separate package-management program.[7][8]” (WP)

History

“Deno was announced on JSConf EU 2018 by Ryan Dahl in his talk “10 Things I Regret About Node.js”.[6] In his talk, Dahl mentioned his regrets about the initial design decisions with Node.js, focusing on his choices of not using promises in API design, usage of the legacy GYP building system, node_modules and package.json, leaving out file extensions, magical module resolution with index.js and breaking the sandboxed environment of V8.[9] He eventually presented the prototype of Deno, aiming to achieve system call bindings through message passing with serialization tools such as Protocol Buffers, and to provide command line flags for access control.” (WP)

“Deno was initially written in Go and used Protocol Buffers for serialization between privileged (Go, with system call access) and unprivileged (V8) sides.[10] However, Go was soon replaced with Rust due to concerns of double runtime and garbage collection pressure.[11] Tokio is introduced in place of libuv as the asynchronous event-driven platform,[12] and FlatBuffers is adopted for faster, “zero-copy” serialization and deserialization[13] but later in August 2019, FlatBuffers were finally removed[14] after publishing benchmarks that measured a significant overhead of serialization in April 2019.[15]” (WP)

“A standard library, modeled after Go’s standard library, was created in November 2018 to provide extensive tools and utilities, partially solving Node.js’ dependency tree explosion problem.[16]” (WP)

“The official Deno 1.0 was released on May 13, 2020.[17]” (WP)

Overview

“Deno aims to be a productive scripting environment for the modern programmer.[7] Similar to Node.js, Deno emphasizes event-driven architecture, providing a set of non-blocking core I/O utilities, along with their blocking versions. Deno could be used to create web servers, perform scientific computations, etc. Deno is open source software under the MIT License.[18]” (WP)

Comparison with Node.js

“Deno and Node.js are both runtimes built on Google’s V8 JavaScript engine, the same engine used in Google Chrome. They both have internal event loops and provide command-line interfaces for running scripts and a wide range of system utilities.” (WP)

“Deno mainly deviates from Node.js in the following aspects:[7]” (WP)

  1. Uses ES Module as the default module system, instead of CommonJS.
  2. Uses URLs for loading local or remote dependencies, similar to browsers.
  3. Includes a built-in package manager for resource fetching, thus no need for npm.
  4. Supports TypeScript out of the box, using a snapshotted TypeScript compiler with caching mechanisms.
  5. Aims for better compatibility with browsers with a wide range of Web APIs.
  6. Allows file system and network access in order to run sandboxed code.
  7. Redesigns API to utilize promises, ES6 and TypeScript features.
  8. Minimizes core API size, while providing a large standard library with no external dependencies.
  9. Using message passing channels for invoking privileged system APIs and using bindings.” (WP)

Releases

VersionLatest micro versionRelease dateDate of last micro versionDescription
0.1.00.1.122018-08-232018-11-12Rust rewrite and V8 snapshot
0.2.00.2.112018-11-272019-02-08Mildly usable
0.3.00.3.102019-02-182019-04-25Instead of importing a “deno” module, there is now a global variable called “Deno”
0.4.00.4.02019-05-032019-05-03
0.5.00.5.02019-05-112019-05-11
0.6.00.6.02019-05-202019-05-20
0.7.00.7.02019-05-292019-05-29
0.8.00.8.02019-06-082019-06-08
0.9.00.9.02019-06-152019-06-15
0.10.00.10.02019-06-252019-06-25
0.11.00.11.02019-07-062019-07-06
0.12.00.12.02019-07-162019-07-16
0.13.00.13.02019-07-312019-07-31
0.14.00.14.02019-08-092019-08-09
0.15.00.15.02019-08-132019-08-13
0.16.00.16.02019-08-222019-08-22
0.17.00.17.02019-09-042019-09-04
0.18.00.18.02019-09-132019-09-13
0.19.00.19.02019-09-242019-09-24
0.20.00.20.02019-10-062019-10-06
0.21.00.21.02019-10-192019-10-19
0.22.00.22.02019-10-282019-10-28
0.23.00.23.02019-11-042019-11-04
0.24.00.24.02019-11-142019-11-14
0.25.00.25.02019-11-262019-11-26
0.26.00.26.02019-12-052019-12-05
0.27.00.27.02019-12-182019-12-18
0.28.00.28.12020-01-022020-01-03
0.29.00.29.02020-01-092020-01-09
0.30.00.30.02020-01-172020-01-17
0.31.00.31.02020-01-242020-01-24
0.32.00.32.02020-02-032020-02-03
0.33.00.33.02020-02-132020-02-13
0.34.00.34.02020-02-202020-02-20
0.35.00.35.02020-02-282020-02-28
0.36.00.36.02020-03-112020-03-11
0.37.00.37.12020-03-232020-03-23
0.38.00.38.02020-03-282020-03-28
0.39.00.39.02020-04-032020-04-03
0.40.00.40.02020-04-082020-04-08
0.41.00.41.02020-04-162020-04-16
0.42.00.42.02020-04-292020-04-29
1.0.01.0.52020-05-132020-06-03
1.1.01.1.32020-06-122020-07-03
1.2.01.2.32020-07-132020-08-08
1.3.01.3.32020-08-132020-09-04
1.4.01.4.62020-09-132020-10-10
1.5.01.5.42020-10-272020-11-23Faster tree-shaking and bundling, refactored REPL
1.6.01.6.32020-12-082020-12-30Compile standalone binaries via “deno compile”, support TypeScript 4.1, experimental support for Mac ARM64
1.7.01.7.52021-02-052021-02-19Cross compilation and 60% smaller binaries for deno compile, a DNS resolver API, support for data URLs in import statements and web workers
1.8.01.8.02021-03-022021-03-02Experimental support for WebGPU API, built-in internationalization APIs enabled, support for fetching private modules, revamped coverage tooling, support for TypeScript 4.2
Legend:Old versionLatest versionFuture release

Via the official Releases[19] page

Example

“This runs a basic Deno script without any file system or network permissions (sandbox mode):” (WP)

deno run main.ts

Explicit flags are required to enable permissions:

deno run --allow-read --allow-net main.ts

To inspect the dependency tree of the script, use the info subcommand:

deno info main.ts

A basic Hello, World! program in Deno looks just like it would in Node.js:

console.log("Hello, World!");

A global Deno namespace exposes APIs that are not available in the browser. A Unix cat program could be implemented as follows:

/* cat.ts */

/* Deno APIs are exposed through the `Deno` namespace. */
const { stdout, open, copy, args } = Deno;

// Top-level await is supported
for (let i = 0; i < args.length; i++) {
    const filename = args[i]; // Obtains command-line arguments.
    const file = await open(filename); // Opens the corresponding file for reading.
    await copy(file, stdout); // Performs a zero-copy asynchronous copy from `file` to `stdout`.
}

The Deno.copy function used above works much like Go’s io.Copy, where stdout (standard output) is the destination Writer, and file is the source Reader. To run this program, we need to enable read permission to the filesystem:

deno run --allow-read cat.ts myfile

The following Deno script implements a basic HTTP server:

// Imports `serve` from the remote Deno standard library, using URL.
import { serve } from "https://deno.land/std@v0.21.0/http/server.ts";

// `serve` function returns an asynchronous iterator, yielding a stream of requests
for await (const req of serve({ port: 8000 })) {
    req.respond({ body: "Hello, World!\n" });
}

When running this program, Deno will automatically download and cache the remote standard library files, and compile the code. Similarly, we can run a standard library script (such as a file server) directly without explicitly downloading, by providing the URL as the input filename (-A turns on all permissions):” (WP)

$ deno run -A https://deno.land/std/http/file_server.ts
Download https://deno.land/std/http/file_server.ts
Compile https://deno.land/std/http/file_server.ts
...
HTTP server listening on http://0.0.0.0:4500/

References

  1. ^ “Contributors, denoland/deno, Github”. Retrieved 5 July 2019.
  2. ^ “Release v1.8.0”. Retrieved 3 March 2021.
  3. ^ “deno/LICENSE at master”GitHub. Retrieved 5 July 2019.
  4. ^ “The MIT License”Open Source Initiative. 17 September 2018. Retrieved 17 September 2018.
  5. ^ “Deno: Secure V8 TypeScript Runtime from Original Node.js Creator”InfoQ. Retrieved 2019-05-17.
  6. a b JSConf (2018-06-06), 10 Things I Regret About Node.js – Ryan Dahl – JSConf EU 2018, retrieved 2019-05-17
  7. a b c “Deno Manual”deno.land. Retrieved 2019-05-17.
  8. ^ Paul Krill (2018-06-21). “Ryan Dahl’s Node.js regrets lead to Deno”InfoWorld.
  9. ^ Dahl, Ryan (2018-06-06). “Design mistakes in Node” (PDF). Github.
  10. ^ “denoland/deno, branch “golang””Github.
  11. ^ “Suggestion: Look into porting to Rust and using Tokio”GitHub.
  12. ^ “Tokio – The asynchronous run-time for the Rust programming language”Tokio.rs.
  13. ^ “Protobuf seems like a lot of overhead for this use case?”Github.
  14. ^ “Remove flatbuffers”GitHub.
  15. ^ “Replace flatbuffers”GitHub.
  16. ^ “denoland/deno_std: deno standard modules”Github.
  17. ^ “Deno 1.0”deno.land. Retrieved 2020-05-14.
  18. ^ “Deno Is Ready for Production”InfoQ. Retrieved 2020-07-01.
  19. ^ “Releases”. 2020-12-30. Retrieved 2021-01-14.

External links

Categories

(WP)

Sources:

Fair Use Sources:

Categories
Software Engineering

Package manager – Package management system – Software package (installation)

package manager or package-management system is a collection of software tools that automates the process of installing, upgrading, configuring, and removing computer programs for a computer‘s operating system in a consistent manner.[1]

A package manager deals with packages, distributions of software and data in archive files. Packages contain metadata, such as the software’s name, description of its purpose, version number, vendor, checksum (preferably a cryptographic hash function), and a list of dependencies necessary for the software to run properly. Upon installation, metadata is stored in a local package database. Package managers typically maintain a database of software dependencies and version information to prevent software mismatches and missing prerequisites. They work closely with software repositoriesbinary repository managers, and app stores.

Package managers are designed to eliminate the need for manual installs and updates. This can be particularly useful for large enterprises whose operating systems are typically consisting of hundreds or even tens of thousands of distinct software packages.[2]

Functions

Illustration of a package manager being used to download new software. Manual actions can include accepting a license agreement or selecting some package-specific configuration options.

A software package is an archive file containing a computer program as well as necessary metadata for its deployment. The computer program can be in source code that has to be compiled and built first.[3] Package metadata include package description, package version, and dependencies (other packages that need to be installed beforehand).

Package managers are charged with the task of finding, installing, maintaining or uninstalling software packages upon the user’s command. Typical functions of a package management system include:

  • Working with file archivers to extract package archives
  • Ensuring the integrity and authenticity of the package by verifying their checksums and digital certificates, respectively
  • Looking up, downloading, installing, or updating existing software from a software repository or app store
  • Grouping packages by function to reduce user confusion
  • Managing dependencies to ensure a package is installed with all packages it requires, thus avoiding “dependency hell

Challenges with shared libraries

Computer systems that rely on dynamic library linking, instead of static library linking, share executable libraries of machine instructions across packages and applications. In these systems, complex relationships between different packages requiring different versions of libraries results in a challenge colloquially known as “dependency hell“. On Microsoft Windows systems, this is also called “DLL hell” when working with dynamically linked libraries. Good package management is vital on these systems.[4] The Framework system from OPENSTEP was an attempt at solving this issue, by allowing multiple versions of libraries to be installed simultaneously, and for software packages to specify which version they were linked against.

Front-ends for locally compiled packages

System administrators may install and maintain software using tools other than package management software. For example, a local administrator may download unpackaged source code, compile it, and install it. This may cause the state of the local system to fall out of synchronization with the state of the package manager’s database. The local administrator will be required to take additional measures, such as manually managing some dependencies or integrating the changes into the package manager.

There are tools available to ensure that locally compiled packages are integrated with the package management. For distributions based on .deb and .rpm files as well as Slackware Linux, there is CheckInstall, and for recipe-based systems such as Gentoo Linux and hybrid systems such as Arch Linux, it is possible to write a recipe first, which then ensures that the package fits into the local package database.[citation needed]

Maintenance of configuration

Particularly troublesome with software upgrades are upgrades of configuration files. Since package managers, at least on Unix systems, originated as extensions of file archiving utilities, they can usually only either overwrite or retain configuration files, rather than applying rules to them. There are exceptions to this that usually apply to kernel configuration (which, if broken, will render the computer unusable after a restart). Problems can be caused if the format of configuration files changes; for instance, if the old configuration file does not explicitly disable new options that should be disabled. Some package managers, such as Debian‘s dpkg, allow configuration during installation. In other situations, it is desirable to install packages with the default configuration and then overwrite this configuration, for instance, in headless installations to a large number of computers. This kind of pre-configured installation is also supported by dpkg.

Repositories

To give users more control over the kinds of software that they are allowing to be installed on their system (and sometimes due to legal or convenience reasons on the distributors’ side), software is often downloaded from a number of software repositories.[5]

Upgrade suppression

When a user interacts with the package management software to bring about an upgrade, it is customary to present the user with the list of actions to be executed (usually the list of packages to be upgraded, and possibly giving the old and new version numbers), and allow the user to either accept the upgrade in bulk, or select individual packages for upgrades. Many package managers can be configured to never upgrade certain packages, or to upgrade them only when critical vulnerabilities or instabilities are found in the previous version, as defined by the packager of the software. This process is sometimes called version pinning.

For instance:

  • yum supports this with the syntax exclude=openoffice*[6]
  • pacman with IgnorePkg= openoffice[7] (to suppress upgrading openoffice in both cases)
  • dpkg and dselect support this partially through the hold flag in package selections
  • APT extends the hold flag through the complex “pinning” mechanism[8] (Users can also blacklist a package[9])
  • aptitude has “hold” and “forbid” flags
  • portage supports this through the package.mask configuration file

Cascading package removal

Some of the more advanced package management features offer “cascading package removal”,[7] in which all packages that depend on the target package and all packages that only the target package depends on, are also removed.

Comparison of commands

Although the commands are specific for every particular package manager, they are to a large extent translatable, as most package managers offer similar functions.

Actionzypper[10]pacmanaptdnf (yum)portage
install packagezypper in PKGpacman -S PACKAGEapt install PACKAGEdnf install PACKAGEemerge PACKAGE
remove packagezypper rm -RU PKGpacman -R PACKAGEapt remove PACKAGEdnf remove --nodeps PACKAGEemerge -C PACKAGE or
emerge --unmerge PACKAGE
remove package+orphanszypper rm -u --force-resolution PKGpacman -Rs PACKAGEapt autoremove PACKAGEdnf remove PACKAGEemerge -c PACKAGE or
emerge --depclean PACKAGE
update software databasezypper refpacman -Syapt updatednf check-updateemerge --sync
show updatable packageszypper lupacman -Quapt list --upgradablednf check-updateemerge -avtuDN --with-bdeps=y @world or
emerge --update --pretend @world
delete orphans+configzypper rm -upacman -Rsn $(pacman -Qdtq)apt autoremovednf erase PKGemerge --depclean
show orphanszypper pa --orphaned --unneededpacman -Qdtpackage-cleanup --quiet --leaves --exclude-binemerge -caD or
emerge --depclean --pretend
update allzypper uppacman -Syuapt upgradednf updateemerge --update --deep --with-bdeps=y @world

The Arch Linux Pacman/Rosetta wiki offers an extensive overview.[11]

Prevalence

Package managers like dpkg have existed as early as 1994.[12]

Linux distributions oriented to binary packages rely heavily on package management systems as their primary means of managing and maintaining software. Mobile operating systems such as Android (Linux-based), iOS (Unix-like), and Windows Phone rely almost exclusively on their respective vendors’ app stores and thus use their own dedicated package management systems.

Comparison with installers

A package manager is often called an “install manager”, which can lead to a confusion between package managers and installers. The differences include:This box: 

CriterionPackage managerInstaller
Shipped withUsually, the operating systemEach computer program
Location of installation informationOne central installation databaseIt is entirely at the discretion of the installer. It could be a file within the app’s folder, or among the operating system’s files and folders. At best, they may register themselves with an uninstallers list without exposing installation information.
Scope of maintenancePotentially all packages on the systemOnly the product with which it was bundled
Developed byOne package manager vendorMultiple installer vendors
Package formatA handful of well-known formatsThere could be as many formats as the number of apps
Package format compatibilityCan be consumed as long as the package manager supports it. Either newer versions of the package manager keep supporting it or the user does not upgrade the package manager.The installer is always compatible with its archive format, if it uses any. However, installers, like all computer programs, may be affected by software rot.

Comparison with build automation utility

Most software configuration management systems treat building software and deploying software as separate, independent steps. A build automation utility typically takes human-readable source code files already on a computer, and automates the process of converting them into a binary executable package on the same computer. Later a package manager typically running on some other computer downloads those pre-built binary executable packages over the internet and installs them.

However, both kinds of tools have many commonalities:

  • For example, the dependency graph topological sorting used in a package manager to handle dependencies between binary components is also used in a build manager to handle the dependency between source components.
  • For example, many makefiles support not only building executables, but also installing them with make install.
  • For example, every package manager for a source-based distribution – PortageSorceryHomebrew, etc. – supports converting human-readable source code to binary executables and installing it.

A few tools, such as Maak and A-A-P, are designed to handle both building and deployment, and can be used as either a build automation utility or as a package manager or both.[13]

Common package managers and formats

Universal package manager

Also known as binary repository manager, it is a software tool designed to optimize the download and storage of binary files, artifacts and packages used and produced in the software development process.[14] These package managers aim to standardize the way enterprises treat all package types. They give users the ability to apply security and compliance metrics across all artifact types. Universal package managers have been referred to as being at the center of a DevOps toolchain.[15]

Package formats

Main articles: Package format and File archive

Each package manager relies on the format and metadata of the packages it can manage. That is, package managers need groups of files to be bundled for the specific package manager along with appropriate metadata, such as dependencies. Often, a core set of utilities manages the basic installation from these packages and multiple package managers use these utilities to provide additional functionality.

For example, yum relies on rpm as a backend. Yum extends the functionality of the backend by adding features such as simple configuration for maintaining a network of systems. As another example, the Synaptic Package Manager provides a graphical user interface by using the Advanced Packaging Tool (apt) library, which, in turn, relies on dpkg for core functionality.

Alien is a program that converts between different Linux package formats, supporting conversion between Linux Standard Base (LSB) compliant .rpm packages, .deb, Stampede (.slp), Solaris (.pkg) and Slackware (.tgz.txz, .tbz, .tlz) packages.

In mobile operating systems, Google Play consumes Android application package (APK) package format while Windows Store uses APPX and XAP formats. (Both Google Play and Windows Store have eponymous package managers.)

Free and open source software systems

By the nature of free and open source software, packages under similar and compatible licenses are available for use on a number of operating systems. These packages can be combined and distributed using configurable and internally complex packaging systems to handle many permutations of software and manage version-specific dependencies and conflicts. Some packaging systems of free and open source software are also themselves released as free and open source software. One typical difference between package management in proprietary operating systems, such as Mac OS X and Windows, and those in free and open source software, such as Linux, is that free and open source software systems permit third-party packages to also be installed and upgraded through the same mechanism, whereas the package managers of Mac OS X and Windows will only upgrade software provided by Apple and Microsoft, respectively (with the exception of some third party drivers in Windows). The ability to continuously upgrade third party software is typically added by adding the URL of the corresponding repository to the package management’s configuration file.

Application-level package managers

See also: List of software package management systems § Application-level package managers

Beside the system-level application managers, there are some add-on package managers for operating systems with limited capabilities and for programming languages in which developers need the latest libraries.

In contrast to system-level package managers, application-level package managers focus on a small part of the software system. They typically reside within a directory tree that is not maintained by the system-level package manager, such as c:\cygwin or /usr/local/fink. However, this might not be the case for the package managers that deal with programming libraries, leading to a possible conflict as both package managers may claim to “own” a file and might break upgrades.

Impact

Ian Murdock had commented that package management is “the single biggest advancement Linux has brought to the industry”, that it blurs the boundaries between operating system and applications, and that it makes it “easier to push new innovations […] into the marketplace and […] evolve the OS”.[16]

See also

” (WP)

Sources:

Fair Use Sources: