|
I would like to try to contribute the following to this thread:
A) Describe the process of building an application for a particular slackware machine
in a way more that is more accessible to *non-programmers* of the forum.
B) My thoughts on where the difference between Debian and Slackware package management
A: THE APPLICATION LIFE CYCLE
-----------------------------
When you (the slackware user) wants to install an application in your slackware machine,
the following process would typically follow:
(Assume the application is written in C language)
1. Download the source code archive of the application from the developer's distribution point.
2. Unpack the source code archive in your machine.
3. The source code archive also contains instructions on how to build the application.
4. The application will have to depend on services provided by other applications. These other applications
are known as libraries. I.e. these libraries are dependencies of the application.
5. In the process of building the application, a special program, called a compiler will read the source code
of the application and turn it into object code (which is understood by the underlying machine)
6. Each library present in the slackware machine has two parts parts:
1) the manifest list of services (header file)
2) archive of object codes that will perform the services listed in (1)
7. The compiler will check that, when the source code of the application uses a particular service of the
library, that service is found in the manifest list of services (header file) of the library.
8. If the library was absent, the compiler cannot proceed. The user is responsible to install the library
into his slackware machine.
Of course, the developer of the application will always have that library installed on his
machine (might not be slackware) so that he could build his own application.
9. By the design of the developer, it is possible for a particular feature of the application that
depends on a particular library to be optionally removed.
In such situation, the library is an optional dependency. I.e., if you do not want
that feature of the application, you do not need to install the library on your slackware machine.
This decision is made by you and is decided before you build the application.
10. When the compiler has examined all the source code of the application and is satisfied
that all the dependencies are satisfied, the object code are generated by the compiler.
11. After that, the last step of the building process happens when all the object codes of the application
are linked together to form the final application program. The special program that does this is called a
linker.
12. Linkers usually do not include the library's archive of object codes into the final application program.
Such library is dynamically linked.
It is also possible, by design of the developer, to instruct the linker to include the
the library's object code into the final application program.
Such library is statically linked.
13. Now that the application is successfully built, the last step is to place it in the correct place
in the slackware machine so that it can be used by everyone.
Note that all library dependencies are already installed.
This is the process where the final application
program and all other files are "installed" onto the slackware machine.
SPECIFIC TO SLACKWARE (Variant 1 - makepkg):
a) Some users decides to package the final application program and other supporting files (excluding library
that the application depend upon) using makepkg.
SPECIFIC TO SLACKWARE (Variant 2 - slackbuild scripts):
a) Some users prefer to use slackbuild.
b) Slackbuild automates all the steps from No. 2 to 13 (or sometimes step 1 to 13)
SPECIFIC TO SLACKWARE (Variant 1 & 2)
Finally, the resultant package is installed onto the slackware machine using installpkg.
14. After the application is installed, you, the slackware user will be able to "open" or "execute" the
application from the command line or an icon in the desktop.
When you open the application, there is a special program (loader) that will make the dynamically linked
library available to the application.
If the library is accidentally removed, the application will not work.
15. And when you decide to remove the application from the slackware machine, you will use removepkg.
removepkg will remove the final application program and all supporting files.
The library that the application depends upon is not removed by removepkg.
SOME THOUGHTS ON PACKAGE MANAGEMENT
-----------------------------------
1. Debian tool for managing packages covers all the steps 1 to 13 and step 15.
2. The repository of Ubuntu/Debian decides (instead of you, the user) what optional feature to include.
3. Follow on from (2), Debian tool knows which library to remove.
4. For slackware user, he decides on the optional feature(s) of the application.
5. Follow on from (4), the slackware user knows which library to remove :-)
6. makepkg, installpkg and removepkg is just a convenient way to deal with application program and supporting
files.
7. For Debian, when the new version of the library is placed in the repository, the tool for managing
packages will automatically update the library.
8. For slackware user, when new version of the library is release, he typically need not use the new library.
He might not even bother if the library is optional to his application.
9. For Debian, when new version of application is in the repository, the tool for managing
packages will automatically update the application (and any new version of library available).
10. For slackware user, he can choose to
a) use the new version of the application with old version of library
b) use the new version of the application with old version of library and enable some optional feature
(and install new dependency, ie new library)
c) continue with old version of application
d) continue with old version of application and enable some optional feature
(and install new dependency, ie new library)
11. Slackware machine's pace of change (updates) are largely controlled by the user,
not a particular repository, library or application.
I hope this helps towards understanding package management done in slackware and the tradeoffs that follows.
Of course, this article is not trying to say which package management way is better.
~alvin
|
