path: root/FAQ
diff options
authorJason Woodward2005-01-10 23:05:32 +0000
committerJason Woodward2005-01-10 23:05:32 +0000
commit410289810dd4fac5386162ef50f7dac98b00a44d (patch)
treefef20e238ebd197ce8d4bfe0e5b5c2898f9e496b /FAQ
parentc572dee80af8b748f92a56f0cedf2731a7c345f8 (diff)
rewrote "Why yet another package management tool for slackware?" and "What about package dependencies?" in FAQ
Diffstat (limited to 'FAQ')
1 files changed, 42 insertions, 71 deletions
diff --git a/FAQ b/FAQ
index ba091eb..b8a75ff 100644
--- a/FAQ
+++ b/FAQ
@@ -64,16 +64,12 @@ Frequenty Asked Questions:
2. Why yet another package management tool for slackware?
- To scratch and itch of mine, which also scratched an itch of a friend. I
- created it originally without looking for an existing solution. I now
- understand Slackware already has existing utilities that provide similar
- functionality. I believe slapt-get to be superior because of its speed and
- simplicity. I do not believe slapt-get takes away anything from these
- existing tools, slapt-get can stand on its own merits. In the end, choice
- is great for the end users (just as in the desktop enviroment category).
- Regardless, I do not aim for inclusion within Slackware. I only want to make
- this availabe in hopes that others will find it useful.
+ Various reasons came together which inspired me to create slapt-get. I was
+ trying to explain to a good friend of mine the functionality provided by
+ apt-get on Debian GNU/Linux. And I needed a uniform and easily scripted
+ method of installing software on on various User-Mode Linux instances I was
+ using for development. Thus slapt-get was born.
3. How do I build/install slapt-get? How do I remove slapt-get?
@@ -197,43 +193,17 @@ Frequenty Asked Questions:
10. What about package dependencies?
- Other tools try to provide dependency checking via various hacks (generating
- the dependency file, exploding the package (or even worse, installing the
- package first just to find a broken dependency!), then ldd'ing binary files to
- find missing libraries before consulting the dependency file). This is not a
- reliable/fool proof method. It is also extremeley slow. Dependencies can not
- always be defined strictly by library dependencies. Applications, rather than
- libraries may be required, such as the case with man and groff. Also, there is
- no ability to specify specific versions of a dependency.
- I believe that package dependency support can be implemented in a Slackware
- compatible way. If we look to the existing infrastructure Pat has created
- for inspiration, we come to the simple addition of another file within the
- packages ./install directory. Let's call it slack-required. This information
- could be as simple as what rules existed in the autoconf scripts of the
- upstream source.
- This file has a simple structure. See FAQ # 19 for an example on the
- structure of an example slack-required file.
- slapt-get can resolve dependencies via the slack-required meta data. Already
- there are packages being submitting to linuxpackages.net supporting this
- optional metadata. Several Slackware derived distributions are also using
- this format: CollegeLinux (starting with 2.5) and VectorLinux (starting with
- 5.0).
- I have made sure that this information does not impact the ability of packages
- to be installed by the existing Slackware package tools. This information
- now simply becomes an additional extension, easily bypassed or simply ignored.
- Slapt-get makes no attempt to force any dependency system on vanilla Slackware
- installations. Using slapt-get on vanilla Slackware is the same as using the
- --no-dep command line option by default.
- The information within slack-required can be added to the PACKAGES.TXT file.
- Scripts that generate mindful PACKAGES.TXT files are available, such as the
- one in this FAQ, see #17.
- So the package's entry within PACKAGES.TXT would go from:
+ First of all, slapt-get does not provide dependency resolution for vanilla
+ Slackware packages.
+ However, slapt-get does provide a framework for dependency resolution for
+ packages that follow the Slackware package format, while still being backwards
+ compatible. This information is stored in so called meta files within the
+ package. slapt-get does not parse packages themselves. It uses the
+ PACKAGES.TXT package database that Patrick Volkerding provides along with his
+ packages. slapt-get uses this file by extending it with optional extra fields.
+ This information is stored within the package simply as a means of easy
+ transport. For example, the entry for man within PACKAGES.TXT looks like:
PACKAGE NAME: man-1.5l-i386-1.tgz
PACKAGE LOCATION: ./slackware/ap
@@ -242,38 +212,39 @@ Frequenty Asked Questions:
man: man (format and display the on-line manual pages)
- to this (note only an additional line per package entry):
+ It is extended like so:
PACKAGE NAME: man-1.5l-i386-1.tgz
PACKAGE LOCATION: ./slackware/ap
PACKAGE SIZE (compressed): 166 K
PACKAGE SIZE (uncompressed): 390 K
- PACKAGE REQUIRES: groff,man-pages
+ PACKAGE REQUIRES: groff >= 1.56-noarch-1,man-pages | man-pages-de
man: man (format and display the on-line manual pages)
- Since dependency information is known when the package is created, that is
- the best time/place to make that data available. It is a simple progression
- from making a note within the package description such as the one already
- within the man package:
- man: man (format and display the on-line manual pages)
- man:
- man: The man package is a collection of tools used for searching and
- man: reading the online system documentation. In fact, on most UNIX-like
- man: operating systems it is the primary means of finding out how programs
- man: on the system work. For example, 'man man' will display the
- man: documentation for man itself.
- man:
- man: *-->*Man requires the groff text processing package.*<--*
- man:
- to providing that data in a way that can be scripted for those who have
- the advanced knowledge or want to provide higher level tools for Slackware.
- I hope if the community as a whole agrees that this is an added benefit they
- can convince Pat there is a need/demand for it.
+ The REQUIRES line is an addition supported by slapt-get, along with CONFLICTS
+ and SUGGESTS. The meta files supporting dependencies, conflicts, and
+ suggestions are within the packages inside the ./install/ directory. The
+ REQUIRES information is stored in the slack-required file. The CONFLICTS
+ information is stored within the slack-conflicts file. The SUGGESTS
+ information is stored in the slack-suggests file. See FAQ #19 for a breakdown
+ of the structure of REQUIRES, FAQ #31 for CONFLICTS, and FAQ #44 for SUGGESTS.
+ This information is added to the PACKAGES.TXT file by extracting it from the
+ meta files within the package. This is normally done by the provider of the
+ packages when they generate the PACKAGES.TXT support file for their package
+ source. See FAQ #17 for an example script to generate an extended PACKAGES.TXT
+ file.
+ The inclusion of this information within the Slackware package format does not
+ inhibit the ability for Slackware pkgtools to install these packages. This
+ information is silently ignored and discarded after the package is installed.
+ Packages supporting this framework can be found at linuxpackages.net, along
+ with several Slackware derived distributions such as CollegeLinux (starting
+ with 2.5) and VectorLinux (starting with 5.0).
11. What about multiple package sources, ala linuxpackages.net?