Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Slackware
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
==Packages== ===Management=== [[File:Slackware-mascot.svg|thumb|upright|The Slackware mascot: [[Tux (mascot)|Tux]] smoking a pipe]] Slackware's package management system, collectively known as pkgtools, can administer ({{Mono|pkgtool}}), install ({{Mono|installpkg}}), upgrade ({{Mono|upgradepkg}}), and remove ({{Mono|removepkg}}) packages from local sources. It can also uncompress ({{Mono|explodepkg}}) and create ({{Mono|makepkg}}) packages. The official tool to update Slackware over a network or the internet is {{Mono|slackpkg}}. It was originally developed by Piter Punk as an unofficial way to keep Slackware up-to-date. It was officially included in the main tree in Slackware 12.2,<ref>{{cite web|url=https://mirrors.slackware.com/slackware/slackware-12.2/CHANGES_AND_HINTS.TXT |format=TXT |title=This file documents the instructions for upgrading to Slackware 12.1, the packages added, removed, renamed, and/or split during the development cycle from Slackware 12.1 through 12.2, and some potential "gotchas" that users can avoid by arming themselves with a little knowledge. |website=Slackware.mirrors.tds.net |access-date=July 22, 2017}}</ref> having been included in {{Mono|extras/}} since Slackware 9.1.<ref name="CL9.1">{{cite web |url=http://slackware.cs.utah.edu/pub/slackware/slackware-9.1/ChangeLog.txt |format=TXT |title=Fixed incorrect type (int copy should be png_size_t copy) in png_inflate() : (fixes CVE-2011-3045). |website=Slackware.cs.utah.edu |access-date=July 22, 2017 |archive-date=February 25, 2021 |archive-url=https://web.archive.org/web/20210225080454/http://slackware.cs.utah.edu/pub/slackware/slackware-9.1/ChangeLog.txt |url-status=live }}</ref> When a package is upgraded, it will install the new package over the old one and then remove any files that no longer exist in the new package. Once a package has been installed with {{Mono|slackpkg}} it can be managed with {{Mono|pkgtool}} or other package management commands.<ref>{{Cite book |last=Kenlon |first=Seth |url=https://books.google.com/books?id=aD-zAwAAQBAJ&dq=%22Slackpkg%22+-wikipedia&pg=PA21 |title=Slackermedia |date=2012-09-01 |publisher=Lulu.com |isbn=978-0-9847842-2-6 |language=en}}</ref> When running {{Mono|upgradepkg}}, it only confirms that the version numbers are ''different'', thus allowing downgrading the package if desired. Slackware packages are [[tar (computing)|tarballs]] compressed using various methods. Starting with 13.0, most packages are compressed using [[XZ Utils|xz]] (based on the [[LZMA]] compression algorithm), utilizing the {{Mono|.txz}} [[filename extension]].<ref>{{cite web |url=https://mirrors.slackware.com/slackware/slackware-13.0/ChangeLog.txt |format=TXT |title=Fixes security issues including : External entity infinite loop DoS |website=Slackware.cs.utah.edu |access-date=July 22, 2017 |archive-date=April 7, 2018 |archive-url=https://web.archive.org/web/20180407120159/https://mirrors.slackware.com/slackware/slackware-13.0/ChangeLog.txt |url-status=live }}</ref> Prior to 13.0, packages were compressed using [[gzip]] (based on the [[DEFLATE]] compression algorithm), using the {{Mono|.tgz}} extension. Support for [[bzip2]] and [[lzip]] compression was also added, using the filename extensions {{Mono|.tbz}} and {{Mono|.tlz}} respectively, although these are not commonly used. Packages contain all the files for that program, as well as additional [[metadata]] files used by the package manager. The package tarball contains the full directory structure of the files and is meant to be extracted in the system's [[root directory]] during installation. The additional metadata files, located under the special {{Mono|install/}} directory within the tarball, usually include a {{Mono|slack-desc}} file, which is a specifically formatted text file that is read by the package manager to provide users with a description of the packaged software,<ref>{{cite web|url=http://www.slackwiki.com/Slack-desc|title=Slack-desc - SlackWiki|website=Slackwiki.com|access-date=July 22, 2017|archive-date=April 3, 2017|archive-url=https://web.archive.org/web/20170403213339/http://www.slackwiki.com/Slack-desc|url-status=live}}</ref> as well as a {{Mono|doinst.sh}} file, which is a post-unpacking [[shell script]] allowing creation of symbolic links, preserving permissions on startup files, proper handling of new configuration files, and any other aspects of installation that can not be implemented via the package's directory structure.<ref>{{cite web|url=http://www.slackwiki.com/Doinst.sh|title=Doinst.sh - SlackWiki|website=Slackwiki.com|access-date=July 22, 2017|archive-date=April 8, 2017|archive-url=https://web.archive.org/web/20170408070248/http://www.slackwiki.com/Doinst.sh|url-status=live}}</ref> During the development of 15.0, Volkerding introduced support for a {{Mono|douninst.sh}} uninstall script that can be launched when removing or upgrading a package.<ref name="CL-current" /> This allows package maintainers to run commands when a package is uninstalled. The package manager maintains a local database on the computer, stored in multiple folders. On 14.2 and older systems, the main database of installed packages was maintained in {{Mono|/var/log/}}, however, during the development of 15.0, Volkerding moved two of the directories to a dedicated location under {{Mono|/var/lib/pkgtools/}} to prevent accidental deletion when clearing system logs.<ref name="CL-current" /> Each Slackware installation will contain a {{Mono|packages/}} and {{Mono|scripts/}} directory in the main database location. The former is where each package installed will have a corresponding install log file (based on the package name, version, arch, and build) that contains the package size, both compressed and uncompressed, the software description, and the full path of all files that were installed.<ref>{{cite web|url=https://docs.slackware.com/slackware:package_management_hands_on#know_more_about_the_contents_of_a_package|title=slackware:package_management_hands_on - SlackDocs|website=Docs.slackware.com|access-date=July 22, 2017|archive-date=November 7, 2016|archive-url=https://web.archive.org/web/20161107191206/https://docs.slackware.com/slackware:package_management_hands_on#know_more_about_the_contents_of_a_package|url-status=live}}</ref> If the package contained an optional {{Mono|doinst.sh}} post-installation script, the contents of that script will be added to a file in the {{Mono|scripts/}} directory matching the filename of the corresponding package in the {{Mono|packages/}} directory, allowing the administrator to view the post-installation script at a future point. When a package is removed or upgraded, the old install logs and scripts found under {{Mono|packages/}} and {{Mono|scripts/}} are moved to {{Mono|removed_packages/}} and {{Mono|removed_scripts/}}, making it possible to review any previous packages and see when they were removed. These directories can be found in {{Mono|/var/log/}} on 14.2 and earlier, but were moved to {{Mono|/var/log/pkgtools/}} during the development of 15.0. On systems supporting the {{Mono|douninst.sh}} uninstall script, those scripts will be stored in the {{Mono|/var/lib/pkgtools/douninst.sh/}} directory while the package is installed. Once removed, the {{Mono|douninst.sh}} script will be moved to {{Mono|/var/log/pkgtools/removed_uninstall_scripts/}}. === Dependency resolution === The package management system does not track or manage ''dependencies''; however, when performing the recommended full install, all dependencies of the stock packages are met. For custom installations or 3rd-party packages, Slackware relies on the user to ensure that the system has all the supporting system libraries and programs required by the program. Since no official lists of dependencies for stock packages are provided, if users decide to install a custom installation or install 3rd-party software, they will need to work through any possible missing dependencies themselves. Since the package manager doesn't manage dependencies, it will install any and all packages, whether or not dependencies are met. A user may find out that dependencies are missing only when attempting to use the software. While Slackware itself does not incorporate official tools to resolve dependencies, some unofficial, community-supported software tools do provide this function, similar to the way [[Advanced Packaging Tool|APT]] does for [[Debian]]-based distributions and [[Yellowdog Updater, Modified|yum]] does for [[Red Hat Enterprise Linux|Red Hat]]-based distributions. They include * [[slapt-get]] is a command line utility that functions in a similar way to APT. While slapt-get does provide a framework for dependency resolution, it does not provide dependency resolution for packages included within the Slackware distribution. However, several community package sources and Slackware based distributions take advantage of this functionality. [[Gslapt]] is a graphical interface to slapt-get. * Swaret is a package management tool featuring dependency resolution. It was originally included in Slackware version 9.1 as an optional package, but did not contain dependency resolution at that time.<ref>{{cite web|url=http://slackware.com/announce/9.1.php|title=The Slackware Linux Project: Slackware Release Announcement|website=Slackware.com|access-date=May 26, 2015|archive-date=June 11, 2015|archive-url=https://web.archive.org/web/20150611153749/http://www.slackware.com/announce/9.1.php|url-status=live}}</ref> It was removed from the distribution with Slackware 10.0 and turned over to the community. It eventually added dependency resolution and roll-back functionality; however, as of May 2014, there are no active developers.<ref>{{cite web|url=https://sourceforge.net/p/swaret/discussion/303953/thread/a4627fcd/?limit=25#22c3|title=SWareT / Discussion / Open Discussion:Is swaret dead?|website=Sourceforge.net|access-date=March 29, 2016|archive-date=May 27, 2016|archive-url=https://web.archive.org/web/20160527162220/https://sourceforge.net/p/swaret/discussion/303953/thread/a4627fcd/?limit=25#22c3|url-status=live}}</ref> * [[NetBSD]]'s [[pkgsrc]] provides support for Slackware, among other Unix-like operating systems. pkgsrc provides dependency resolution for both binary and source packages.{{citation needed|reason=This claim needs a reliable source; official website of pkgsrc says it only supports Enterprise Linux, no mention of Slackware, Link=https://pkgsrc.joyent.com/install-on-linux/|date=June 2020}} ===Repositories=== There are no official repositories for Slackware. The only official packages Slackware provides are available on the installation media. However, there are many third-party repositories for Slackware; some are standalone repositories and others are for distributions that are Slackware-based but retain package compatibility with Slackware. Many of these can be searched at once using pkgs.org, which is a Linux package search engine. However, mixing and matching dependencies from multiple repositories can lead to two or more packages that require different versions of the same dependency, which is a form of [[dependency hell]]. Slackware itself won't provide any dependency resolution for these packages, however some projects will provide a list of dependencies that are not included with Slackware with the files for the package, commonly with a {{Mono|.dep}} extension. Due to the possibility of dependency issues, many users choose to compile their own programs using community-provided SlackBuilds. SlackBuilds are shell scripts that will create an installable Slackware package from a provided software tarball. Since SlackBuilds are scripts, they aren't limited to just compiling a program's source; they can also be used to repackage pre-compiled binaries provided by projects or other distributions' repositories into proper Slackware packages. SlackBuilds that compile sources have several advantages over pre-built packages: since they build from the original author's [[source code]], the user does not have to trust a third-party packager; furthermore the local compilation process allows for machine-specific optimization. In comparison to manual compilation and installation of software, SlackBuilds provide cleaner integration to the system by utilizing Slackware's package manager. Some SlackBuilds will come with an additional file with metadata that allows automated tools to download the source, verify the source is not corrupt, and calculate additional dependencies that are not part of Slackware.<ref>{{cite web|url=https://slackbuilds.org/guidelines/#info|title=SlackBuilds.org|first=WebSight Designs -|last=websightdesigns.com|website=Slackbuilds.org|access-date=January 15, 2017|archive-date=January 16, 2017|archive-url=https://web.archive.org/web/20170116174913/https://slackbuilds.org/guidelines/#info|url-status=live}}</ref> Some repositories will include both SlackBuilds and the resulting Slackware packages, allowing users to either build their own or install a pre-built package. The only officially endorsed<ref>{{cite web|url=http://www.linuxquestions.org/questions/slackware-14/slackware-14-2-is-coming-but-will-the-slackbuilds-will-also-be-updated-accordingly-4175575223/#post5517961|title=Slackware 14.2 is coming, but will the slackbuilds will also be updated accordingly?|website=Linuxquestions.org|access-date=March 19, 2016|archive-date=March 22, 2016|archive-url=https://web.archive.org/web/20160322090136/http://www.linuxquestions.org/questions/slackware-14/slackware-14-2-is-coming-but-will-the-slackbuilds-will-also-be-updated-accordingly-4175575223/#post5517961|url-status=live}}</ref> SlackBuilds repository is SlackBuilds.org, commonly referred to as SBo. This is a community-supported project offering SlackBuilds for building software not included with Slackware. Users are able to submit new SlackBuilds for software to the site and, once approved, they become the "package maintainer". They are then responsible for providing updates to the SlackBuild, either to fix issues or to build newer versions provided by [[Upstream (software development)|upstream]]. To ensure all programs can be compiled and used, any required dependencies of the software not included with Slackware are required to be documented and be available on the site. All submissions are tested by the site's administrators before being added to the repository. The administrators intend for the build process to be nearly identical to the way Slackware's official packages are built, mainly to ensure Volkerding was "sympathetic of our cause". This allows SlackBuilds that Volkerding deems worthy to be pulled into regular Slackware with minimal changes to the script. It also prevent users from suggesting Volkerding to change his scripts to match SBo's.<ref>{{cite web|url=http://alien.slackbook.org/blog/ten-years-of-slackbuilds-org/|title=Ten years of SlackBuilds.org|date=June 10, 2016|website=Alien.dslackbook.org|access-date=July 22, 2017|archive-date=August 3, 2017|archive-url=https://web.archive.org/web/20170803091637/http://alien.slackbook.org/blog/ten-years-of-slackbuilds-org/|url-status=live}}</ref> SBo provides templates<ref>{{cite web|url=https://slackbuilds.org/templates|title=Index of /templates|website=Slackbuilds.org|access-date=January 15, 2017|archive-date=January 18, 2017|archive-url=https://web.archive.org/web/20170118032729/https://slackbuilds.org/templates/|url-status=live}}</ref> for SlackBuilds and the additional metadata files and they encourage package maintainers to not deviate unless necessary.<ref>{{cite web|url=https://slackbuilds.org/guidelines/|title=WebSight Designsm|website=Slackbuilds.org|access-date=January 15, 2017|archive-date=January 16, 2017|archive-url=https://web.archive.org/web/20170116174913/https://slackbuilds.org/guidelines/|url-status=live}}</ref> Two Slackware team members, Eric Hameleers and Robby Workman each have their own repository of pre-compiled packages along with the SlackBuilds and source files used to create the packages. While most packages are just additional software not included in Slackware that they felt was worth their time to maintain, some packages are used as a testbed for future upgrades to Slackware, most notably, Hameleers provides "Ktown" packages for newer versions of [[KDE]].<ref>{{cite web|url=http://alien.slackbook.org/ktown/|title=Index of /ktown|website=Alien.slackbook.org|access-date=January 15, 2017|archive-date=December 31, 2016|archive-url=https://web.archive.org/web/20161231121150/http://alien.slackbook.org/ktown/|url-status=live}}</ref> He also maintains Slackware's "multilib" repository, enabling Slackware64 to run and compile 32-bit packages.<ref name="multilib"/>
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)