aboutsummaryrefslogtreecommitdiffstats
path: root/FAQ.html
diff options
context:
space:
mode:
Diffstat (limited to 'FAQ.html')
-rw-r--r--FAQ.html113
1 files changed, 42 insertions, 71 deletions
diff --git a/FAQ.html b/FAQ.html
index 37065dc..7870c3e 100644
--- a/FAQ.html
+++ b/FAQ.html
@@ -78,16 +78,12 @@
<A NAME="slgFAQ2"><B>2. Why yet another package management tool for slackware?</B></A>
- 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.
+
<A NAME="slgFAQ3"><B>3. How do I build/install slapt-get? How do I remove slapt-get?</B></A>
@@ -211,43 +207,17 @@
<A NAME="slgFAQ10"><B>10. What about package dependencies?</B></A>
- 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 <A href="#slgFAQ19">FAQ # 19</A> 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, <A href="#slgFAQ17">see #17.</A>
-
- 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
@@ -256,38 +226,39 @@
PACKAGE DESCRIPTION:
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 &gt;= 1.56-noarch-1,man-pages | man-pages-de
+ PACKAGE CONFLICTS:
+ PACKAGE SUGGESTS:
PACKAGE DESCRIPTION:
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: *--&gt;*Man requires the groff text processing package.*&lt;--*
- 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 <a href="#slgFAQ19">FAQ #19</a> for a breakdown
+ of the structure of REQUIRES, <a href="#slgFAQ31">FAQ #31</a> for CONFLICTS, and <a href="#slgFAQ44">FAQ #44</a> 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 <a href="#slgFAQ17">FAQ #17</a> 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).
<A NAME="slgFAQ11"><B>11. What about multiple package sources, ala linuxpackages.net?</B></A>