Linux Package Management (Distribute Your App)

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
(→Appendix)
m
 
(23 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
__NOTOC__
 
__NOTOC__
−
{| border="1"
+
 
−
|-
+
{{Learning Activity Overview
−
|'''Title''' || Linux package management (Packing the 'htop' command)
+
|title=
−
|-
+
Linux RPM package management Part 1 (Packaging the 'htop' command)
−
|'''Overview''' || Students will learn about rpm and dnf/yum package tooling and then actually create their own package from code, upload it to a public package repository and finally have a classmate install their compiled package. This can be advertised to students as being able to distribute their own linux-based application to the world.
+
|overview=
−
|-
+
Students will learn about <code>rpm</code> and <code>dnf</code>/<code>yum</code> package tooling and then actually create their own RPM package from code.  
−
|'''Prerequisite Knowledge''' ||  Students should be familiar with:
+
This can be advertised to students as being able to distribute their own Linux-based application to the world.
−
* Beginner to Intermediate Shell knowledge (linux command line)
+
|prerequisites=
−
** Getting around the linux file system, sudo'ing, editing files, etc.
+
Students should be familiar with:
 +
* Beginner to Intermediate Shell knowledge (Linux command line)
 +
** Getting around the Linux file system, <code>sudo</code>'ing, editing files, etc.
 
* Making and compiling Linux software code
 
* Making and compiling Linux software code
−
** see extended note in Comments section below
+
** see extended note in the [[#Comments:|Comments]] section below
−
|-
+
|objectives=
−
|'''Learning Objectives''' || Upon completion, students should be able to:
+
* Install RPM's and use the <code>dnf</code>/<code>yum</code> command to install and inspect packages
−
* Install RPM's and use the dnf/yum command to inspect and install packages
+
* Create a compliant .spec file
−
* Make and Compile existing code into a binary RPM package
+
* Build an RPM from existing code and assure that it works
−
* Upload a package to an online repository
+
* Keep a working log and cheat sheet of command-line history
−
* Install a package from an online repository
+
|process skills=
−
|}
+
}}
  
−
=== Background: ===
+
=== Background ===
−
Is there background reading material?
+
''Is there background reading material?''
−
* http://www.howtogeek.com/191245/beginner-geek-how-to-install-software-on-linux/ - Read about the various software installation methods on Linux
+
* http://www.control-escape.com/linux/lx-swinstall.html - Various methods to install Linux software
−
* http://www.control-escape.com/linux/lx-swinstall.html
+
* http://www.howtogeek.com/191245/beginner-geek-how-to-install-software-on-linux/ - Ubuntu-oriented version of the above
−
* https://help.ubuntu.com/community/SoftwarePackagingFormats
+
* https://help.ubuntu.com/community/SoftwarePackagingFormats - This document summarizes major Linux software packaging formats.
−
* http://www.rpm.org/wiki/Docs
+
* http://www.rpm.org/wiki/Docs - List of books and documentation for RPM
−
* https://en.m.wikipedia.org/wiki/DNF_(software)
+
* https://en.m.wikipedia.org/wiki/DNF_(software) - General DNF information
  
 +
''Are there other related activities?''
 +
* [[Linux Beginner Activity]] - Students can follow this to get command-line basics.
 +
** Note that the requirements above ask for slightly more in-depth command-line experience via <code>sudo</code> and code compilation.
 +
* [[Installing a Virtual Machine]] - If Students need virtual Linux machines for command-line access, they can use this activity.
 +
* [[Introduction to Building Open Source Software]] and [[Build a GnomeMusic Clone (Activity)]] both give Linux compilation and build experience.
  
−
Are there other related activities?
+
''What is the rationale for this activity?''
−
* [[Linux_Beginner_Activity]] - Students can follow this to get command-line basics.
+
* Students may wonder how they can distribute Linux-based code that they develop out to other everyday users. Not many users enjoy compiling code, so the RPM package structure allows easy installation of binary pre-compiled code packages. Basically, a student could have coded a small sample command-line application and now they can send it to others easily. The other side of it is that students, as users of Linux, will be interfacing with RPM packages not of their making and it will be good to have an understanding of the backends of how this works. Students will interface with the <code>dnf</code> and <code>yum</code> commands even if simply using Linux for fun. Now, they can have knowledge into how it works and how they can employ it for their careers and personal uses.
−
** Note that the requirements above ask for slightly more in-depth command-line experience via sudo and code compilation.
+
−
* [[Installing_a_Virtual_Machine]] - If Students need virtual linux machines for command-line access, they can use this activity.
+
−
* [[Introduction_to_building_open_source_software]] and [[Building_a_GnomeMusic_Clone]] both give linux compilation and build experience.
+
  
  
−
What is the rationale for this activity?
+
=== Directions ===
−
* Students may wonder how they can distribute linux-based code that they develop out to other everyday users. Not many users enjoy compiling code, so the RPM package structure allows easy installation of binary pre-compiled code packages. Basically, a student could have coded a small sample command-line application and now they can send it to others easily. The other side of it is that students, as users of Linux, will be interfacing with RPM packages not of their making and it will be good to have an understanding of the backends of how this works. Students will interface with the dnf and yum commands even if simply using linux for fun. Now, they can have knowledge into how it works and how they can employ it for their careers and personal uses.
+
  
 +
==== Keep a working log ====
  
−
=== Directions: ===
+
Log your shell commands, answers to questions, and commentary in a text file, wiki, or blog. You will be constructing and troubleshooting numerous Linux shell command's and their outputs. Your assignment is to document these commands and the process you went through in an organized fashion. You might use bullet points or a new set of commands on each line. Make sure it is easily consumable by a human (your instructor), as well as yourself 10 years from now.
  
−
==== Keep a working log ====
+
The data that is the output of the commands is not as interesting as key lines or a summary/comment of their output or on what the command has done - ex: failed, succeeded, why, what it did, what it changed, etc. Write these in complete sentences. Commentary is especially important if you run into problems. When this occurs, state the problem and how you intend to solve it. At the end, you should have a text document with all of the commands, right and wrong, that you went through to get this activity completed. It should read as a timeline of what you did and what your thoughts were, to get the assignment complete. After this is complete, you will summarize the most useful commands into a sort of cheat sheet - this can come in useful for years to come.
−
Log your shell commands, answers to questions, and commentary in a text file, wiki, or blog. You will be constructing and troubleshooting numerous linux shell command's and their outputs. Your assignment is to document these commands and the process you went through in an organized fashion. You might use bullet points or a new set of commands on each line. Make sure it is easily consumable by a human (your instructor), as well as yourself 10 years from now.
+
 
 +
See some samples and tools for a working log. Whatever method you use, make your written log human readable, make it a story if you wish. When you come back to this years from now, needing to remind yourself how to package some newly minted code, you want a summary/cheat sheet and you want to be able to understand the context and follow your thoughts of why you tried certain things. You don't want to be parsing through lines and lines of shell input and output.
 +
 
 +
===== Working log examples =====
 +
 
 +
* http://nickyeates.com/technology/unix/lms/linux_log#retry_to_recover_2x_320_gb_hdds
 +
* http://nickyeates.com/technology/unix/raid_filesystem_lvm
  
−
The data that is the output of the commands is not as interesting as a summary or comment of their output or on what the command has done - ex: failed, succeeded, why, what it did, what it changed, etc. Write these in complete sentences. Commentary is especially important if you run into problems. When this occurs, state the problem and how you intend to solve it. At the end, you should have a text document with all of the commands, right and wrong, that you went through to get this activity completed. It should read as a timeline of what you did and what your thoughts were, to get the assignment complete. After this is complete, you will summarize the most useful commands into a sort of cheatsheet - this can come in useful for years to come.
+
===== Working log Tools to help you =====
 +
 
 +
* ''history'' command - Use this command to see what commands you have typed in the past.  
 +
* ''script'' command - You may alternately want to use the ''script'' command, which records all commands and their output to a file. The downside is that you have to remember to run this command before you wanted that output.  
 +
* Multiple terminal windows/tabs - It is advised that you utilize multiple terminal (shell) windows at the same time. When you get sidetracked on installing a dependency, use a separate window for that. This keeps your shell history organized and parsable afterwards.
 +
* Up your terminals buffer limit - You might also consider upping your terminal windows buffer for the number of lines it holds, to somewhere in the tens of thousands - just in case you decide you want to come back to something you learned a while back, or in case a command spits out thousands of lines of results - which can happen. Some terminal applications can record commands and output to text files.
  
−
The ''history'' command is your friend. Use it to see what commands you have typed in the past. It is advised that you utilize multiple terminal (shell) windows at the same time. When you get sidetracked on installing a dependency, use a separate window for that. This keeps your shell history organized and parsable afterwards. You might also consider upping your terminal windows buffer for the number of lines it holds, to somewhere in the tens of thousands - just in case you decide you want to come back to something you learned a while back, or in case a command spits out thousands of lines of results - which can happen. Some terminal applications can record commands and output to text files. Either way, make your written log human readable, make it a story if you wish. When you come back to this years from now, needing to remind yourself how to package some newly minted code, you want a summary/cheatsheet and you want to be able to understand the context and follow your thoughts of why you tried certain things. You don't want to be parsing through lines and lines of shell input and output.
 
  
  
 
==== The activity will follow these general steps ====
 
==== The activity will follow these general steps ====
 +
 
# Use dnf/yum and rpm files.
 
# Use dnf/yum and rpm files.
 
# Learn about creating rpm's and the rpmbuild command.
 
# Learn about creating rpm's and the rpmbuild command.
Line 56: Line 71:
  
 
==== Step 1: dnf / yum and .rpm's ====
 
==== Step 1: dnf / yum and .rpm's ====
 +
 
* First, lets do some learning before we jump into shell commands. Answer the following in your log:
 
* First, lets do some learning before we jump into shell commands. Answer the following in your log:
 
** What is the difference between dnf and yum? Why was the change made?
 
** What is the difference between dnf and yum? Why was the change made?
Line 71: Line 87:
  
 
==== Step 2: RPM's and rpmbuild ====
 
==== Step 2: RPM's and rpmbuild ====
 +
 
Required reading / watching:
 
Required reading / watching:
 
# [https://www.youtube.com/watch?v=4J_Iksu1fgo&feature=youtu.be RPM Build Example Video] - Watch, at least, the first 8 mins of this video from a recording of a local Linux User Group meeting
 
# [https://www.youtube.com/watch?v=4J_Iksu1fgo&feature=youtu.be RPM Build Example Video] - Watch, at least, the first 8 mins of this video from a recording of a local Linux User Group meeting
 
# [ftp://ftp.eso.org/midaspub/RPMS-tutorial/GURULABS-RPM-GUIDE-v1.0.PDF RPM process Diagram from video] - Find the diagram that the video references on the page labeled 12-17
 
# [ftp://ftp.eso.org/midaspub/RPMS-tutorial/GURULABS-RPM-GUIDE-v1.0.PDF RPM process Diagram from video] - Find the diagram that the video references on the page labeled 12-17
 
#* Document authored by Guru Labs, L.C. released under the CC-BY-NC-ND 2.0 license
 
#* Document authored by Guru Labs, L.C. released under the CC-BY-NC-ND 2.0 license
−
# [http://www.ibm.com/developerworks/library/l-rpm1/ Packaging the `wget` command] - Read this example in its entirety
+
# [http://www.ibm.com/developerworks/library/l-rpm1/ Packaging the `wget` command] - Review this example in its entirety
−
#* This will take some time to read through.
+
#* This will take some time to read, but don't worry about details, as we will step through it again below.
−
#* If you were to try to follow along in the shell, there may be some hickups with ''wget''.
+
#* If you were to try to follow along in the shell, there may be some difficulties with ''wget''.
−
#* Instead, save it for Part 3; You will use this readings structure to RPM'ize the ''htop'' project.
+
#* Instead, save it for Part 3 below; You will use this readings structure to turn the ''htop'' code into an RPM.
−
 
+
  
 
Questions:
 
Questions:
−
* What is the rpmbuild command?
+
* What is a source RPM vs binary RPM?
 +
* What does the rpmbuild command do?
 
* Quickly summarize the directory structure when making your own RPM - you will stick this into your cheat sheet later, so make it short.
 
* Quickly summarize the directory structure when making your own RPM - you will stick this into your cheat sheet later, so make it short.
  
  
 +
==== Step 3: Create your own 'htop' RPM ====
  
−
==== Step 3: Create your own 'htop' RPM ====
 
 
In this section, we will take code from the ''htop'' project and turn it into an RPM package.
 
In this section, we will take code from the ''htop'' project and turn it into an RPM package.
  
Line 96: Line 113:
  
 
Instructions:
 
Instructions:
−
* [http://www.ibm.com/developerworks/library/l-rpm1/ Packaging a command] - With all of the below instructions, you will be following this example, except replace it with ''htop''
+
* Required: Follow along with these resources:
−
 
+
** PRIMARY - http://www.ibm.com/developerworks/library/l-rpm1/ - With all of the below instructions, you will be following this example, except replace it with ''htop''
 +
** Secondary: https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package - This second resource also steps through packaging. It takes some shortcuts, and therefore you miss out on some details, but it also simplifies the entire process. You should use it to follow along with the above example.
  
 
* Build ''htop'' manually
 
* Build ''htop'' manually
 
** Compile the ''htop'' project to test that the code can be turned into binary form in your environment.
 
** Compile the ''htop'' project to test that the code can be turned into binary form in your environment.
 
** Before you can create an RPM, code '''must''' compile manually.
 
** Before you can create an RPM, code '''must''' compile manually.
−
** Dependancy issues: see appendix for detailed configure and make issues that you might run into.
+
** See [[#Dependency_Issues|Dependency Issues]] in the appendix below for detailed configure and make issues that you might run into.
 
** Once you have ./configure, make, and make install compiling ''htop'', you can move on to building an RPM for it
 
** Once you have ./configure, make, and make install compiling ''htop'', you can move on to building an RPM for it
−
 
  
 
* Create RPM dir structure
 
* Create RPM dir structure
−
* Run ''rpmbuild'' command
+
** It should look like:
−
* FIXME
+
**:<pre>
 +
**:: [nyeates@localhost myhtop]$ ls
 +
**:: BUILD  RPMS  SOURCES  SPECS  SRPMS</pre>
 +
** Place your tar.gz file into the SOURCES directory
 +
** Assure that you stick to the naming convention "package-version.tar.gz"
  
 +
* Create the .spec file
 +
**:<pre>
 +
**:: vi SPECS/htop.spec</pre>
 +
** Fill in all required information in the .spec file
 +
** Borrow from these two examples of .spec files:
 +
*** http://www.ibm.com/developerworks/library/l-rpm1/#list3
 +
*** https://fedoraproject.org/wiki/How_to_create_a_GNU_Hello_RPM_package#Inside_a_.spec_file
  
 +
* Build an RPM and test that it works
 +
** Run ''rpmbuild'' command
 +
** Use ''rpmlint'' and ''mock'' to verify that the created .RPM works
 +
** (Optional) You might try to ''dnf install'' the RPM on a separate computer or shell to see that it really works
 +
*** This is not required for this activity
 +
 +
=== Deliverables ===
 +
 +
One single text document can hold all of what needs to be handed in below.
 +
Put them in the following order, first to last, so that the instructor can find them easily.
  
−
=== Deliverables: ===
 
 
Students will hand in:
 
Students will hand in:
−
* The working log
 
−
** See the above lengthy note about the working log.
 
 
* Cheat sheet / Summary
 
* Cheat sheet / Summary
 
** A quick-reference guide, truly meant for your future use.
 
** A quick-reference guide, truly meant for your future use.
−
** List key commands and what they do
+
** List key commands and what they do.
−
** Succinctly explain the RPM directory structure
+
** Succinctly explain the RPM directory structure.
−
 
+
* Answers to specific questions
 +
** 1-3 sentance answers to the questions asked throughout the above activity.
 +
* The working log
 +
** See the above lengthy note about the working log.
  
 +
=== Assessment ===
  
−
=== Assessment: ===
 
 
{| border="1" class="wikitable"
 
{| border="1" class="wikitable"
 
! Criteria
 
! Criteria
Line 132: Line 170:
 
|-
 
|-
 
| '''Installs and inspects RPMs with dnf/yum'''
 
| '''Installs and inspects RPMs with dnf/yum'''
−
|  
+
| Did not attempt commands
−
|  
+
| Attempted to install RPM, but was unsuccessful
−
|
+
| Installed RPM and showed that it is installed
−
|
+
| Installed RPM, showed that it is installed, and ran the installed binary
  
 
|-
 
|-
−
| '''Compiles code into binary RPM'''
+
| '''Creates a compliant .spec file'''
−
|  
+
| Did not attempt to create file
−
|  
+
| Creates file, but minimally fills out metadata
−
|  
+
| Creates file, fills out metadata
−
|  
+
| Creates file, fills out metadata, and adds comments
  
 
|-
 
|-
−
| '''Uploads RPM to COPR or other online repo'''
+
| '''Builds an RPM and assures that it works'''
−
|  
+
| Did not attempt to build RPM
−
|  
+
| Attempted to build RPM, but was unsuccessful
−
|  
+
| Built RPM
−
|  
+
| Built RPM and assured that it works with rpmlint, mock and/or dnf install
  
 
|-
 
|-
−
| '''Installs colleagues RPM from COPR'''
+
| '''Creates a working log and cheat sheet of commands'''
−
|  
+
| Did not create a working log
−
|  
+
| Created a minimal working log that shows only commands and their output - no user comments
−
|  
+
| Created working log that explains commands and summarizes with a cheat sheet
−
|  
+
| Created working log that contains an easy to follow narrative of commands and reasons why they were run; Summarizes with a cheat sheet that is very easy to reference and understand
  
 
|}
 
|}
  
−
=== Comments: ===
 
−
What should the instructor know before using this activity?
 
  
−
Students should know how to compile Linux software code before doing this activity.
+
=== Comments ===
−
* There exists an activity which covers this: [[Introduction_to_building_open_source_software]]
+
''What should the instructor know before using this activity?''
−
* Particularly, students should have experience using the ''configure'', ''make'', and ''make install'' commands
+
−
* If students have not compiled in the past, it is common to not have all of the required libraries and modules already installed for the compilation process to succeed. This is a major part of creating RPM's. This setup takes time to troubleshoot and setup, and it could be different on each system if students are not using identical operating systems.
+
  
 +
* Students should know how to compile Linux software code before doing this activity.
 +
** There exists an activity which covers this: [[Introduction_to_building_open_source_software]]
 +
** Particularly, students should have experience using the ''configure'', ''make'', and ''make install'' commands
 +
** If students have not compiled in the past, it is common to not have all of the required libraries and modules already installed for the compilation process to succeed. This is a major part of creating RPM's. This setup takes time to troubleshoot and setup, and it could be different on each system if students are not using identical operating systems.
  
−
If you wanted to do this activity in Ubuntu, Debian, etc:
+
*If you wanted to do this activity in Ubuntu, Debian, etc:
−
* Students could optionally do this activity on Ubuntu or other Linux OS's which use a different Package Management toolset.  
+
** Students could optionally do this activity on Ubuntu or other Linux OS's which use a different Package Management toolset.  
−
* Ubuntu is debian-based and uses the ``dpkg`` command. For more info on equivalent commands, see:
+
** Ubuntu is debian-based and uses the ``dpkg`` command. For more info on equivalent commands, see:
−
** http://wiki.openvz.org/Package_managers
+
*** http://wiki.openvz.org/Package_managers
−
** http://askubuntu.com/questions/85839/deb-equivalents-to-rpm-commands/85849
+
*** http://askubuntu.com/questions/85839/deb-equivalents-to-rpm-commands/85849
  
−
What are some likely difficulties that an instructor may encounter using this activity?
+
''What are some likely difficulties that an instructor may encounter using this activity?''
  
 +
* Instructors may run into students having build problems. The instructor should implement the commands of this activity on a machine themselves. You may still run into student problems that you did not see, but at least you have the context.
 +
* If you allow students to run on their own systems, there may be more of these compatibility problems. Consider a lab / virtual machine environment or telling students that are on their own environments that they will need to support themselves.
  
  
−
=== Additional Information: ===
+
=== Additional Information ===
−
{| border="1"
+
 
−
|-
+
{{Learning Activity Info
−
|'''ACM Knowledge Area/Knowledge Unit''' || PL - Programming Languages, SE - Software Engineering from [[ACM_Body_of_Knowledge]]
+
|acm unit=
−
|-
+
PL - Programming Languages, SE - Software Engineering
−
|'''ACM Topic''' || PL/Compiler Semantic Analysis, PL/Code Generation, SE/Tools and Environments from https://www.acm.org/education/CS2013-final-report.pdf
+
|acm topic=
−
|-
+
PL/Compiler Semantic Analysis, PL/Code Generation, SE/Tools and Environments
−
|'''Level of Difficulty''' || Easy-Medium, for students that meet the pre-req's
+
|difficulty=
−
|-
+
Easy-Medium, for students that meet the pre-reqs
−
|'''Estimated Time to Completion''' ||  2-3 hours
+
|time=
−
|-
+
3-4 hours
−
|'''Materials/Environment''' ||
+
|environment=
 
* Access to the shell of a Linux operating system that uses RPM (virtualized or on hardware can work)
 
* Access to the shell of a Linux operating system that uses RPM (virtualized or on hardware can work)
−
* root access is likely needed - another good vote for virtualized systems (might use openshift or virtualbox)
+
* root access is likely needed - another good vote for virtualized systems (might use virtualbox)
−
|-
+
|author=
−
|'''Author''' || Nick Yeates
+
Nick Yeates
−
|-
+
|source=
−
|'''Source''' ||
+
|license=
−
|-
+
{{License CC BY}}
−
|'''License''' || Creative Commons CC-BY
+
}}
−
|}
+
  
−
=== Suggestions for Open Source Community: ===
+
=== Suggestions for Open Source Community ===
−
Suggestions for an open source community member who is working in conjunction with the instructor:
+
 
 +
''Suggestions for an open source community member who is working in conjunction with the instructor:''
 
* Why did your community decide to standardize on the autotools-based config/make building? Or, why not?
 
* Why did your community decide to standardize on the autotools-based config/make building? Or, why not?
 
* Explain to students why packaging skills can be used on many open source linux-based projects, across their careers.
 
* Explain to students why packaging skills can be used on many open source linux-based projects, across their careers.
Line 208: Line 248:
 
* Help students to find alternate examples to step through - aka, finding project code other than the ones listed above and making it into an RPM.
 
* Help students to find alternate examples to step through - aka, finding project code other than the ones listed above and making it into an RPM.
  
 +
=== Appendix ===
  
 +
==== Dependency Issues ====
  
−
--------------------
+
* ''htop'' may provide you with issues when running ./configure, make, and make install; Find some solutions below.
−
This work is licensed under a
+
** There is always some odd ./configure setting or dependency that needs installing (this means, other rpm packages that this project needs installed in order to compile)
−
[http://creativecommons.org/licenses/by/4.0/ Creative Commons Attribution 4.0 International License]
+
** Unfortunately, these dependencies are not installed automatically - you must install them yourself and then try to ./configure or make again
−
 
+
−
 
+
−
[[Category: Learning_Activity]]
+
−
[[Category: Coding_and_Style]]
+
−
[[Category: Product_Packaging_and_Distribution]]
+
−
[[Category: Use_and_Evaluate]]
+
−
 
+
−
 
+
−
=== Appendix ===
+
−
 
+
−
''Htop'' dependency issues:
+
−
* There is always some odd ./configure setting or dependency that needs installing (this means, other rpm packages that this project needs installed in order to compile)
+
−
* Unfortunately, these dependencies are not installed automatically - you must install them yourself and then try to ./configure or make again
+
 
* Some dependency issues you might run into with ''htop'':  
 
* Some dependency issues you might run into with ''htop'':  
 
** gcc, try each of these commands one at a time:
 
** gcc, try each of these commands one at a time:
 
**:<pre>
 
**:<pre>
−
**::sudo dnf install glibc-devel glibc-headers kernel-headers kernel-devel gnutls-devel
+
**:: sudo dnf install glibc-devel glibc-headers kernel-headers kernel-devel gnutls-devel
−
**::sudo dnf groupinstall "Development Tools"
+
**:: sudo dnf groupinstall "Development Tools"
−
**::sudo dnf install gnutls</pre>
+
**:: sudo dnf install gnutls
 +
**:: # answer from http://stackoverflow.com/questions/18076157/why-does-configure-say-no-c-compiler-found-when-gcc-is-installed</pre>
 
** libncurses or unicode, "configure: error: You may want to use --disable-unicode or install libncursesw."
 
** libncurses or unicode, "configure: error: You may want to use --disable-unicode or install libncursesw."
 
**:<pre>
 
**:<pre>
 
**:: ./configure --disable-unicode  # first try disabling unicode like they suggest
 
**:: ./configure --disable-unicode  # first try disabling unicode like they suggest
 
**:: which ncurses                  # ncurses is usually already installed, but if not, you will need to dnf install it also
 
**:: which ncurses                  # ncurses is usually already installed, but if not, you will need to dnf install it also
−
**:: sudo dnf install ncurses-devel  # try installing the ncurses-developer library package</pre>
+
**:: sudo dnf install ncurses-devel  # try installing the ncurses-developer library package
 +
**:: # answer from http://www.linuxquestions.org/questions/linux-software-2/error-while-try-to-install-htop-0-8-a-655823/</pre>
 
* Some make issues you might run into with ''htop'':
 
* Some make issues you might run into with ''htop'':
 
** Permission denied, "/usr/bin/install: cannot create regular file '/usr/local/bin/htop': Permission denied"
 
** Permission denied, "/usr/bin/install: cannot create regular file '/usr/local/bin/htop': Permission denied"
 
**:<pre>
 
**:<pre>
−
**:: sudo make install         # your local account didnt have permissions to touch that directory</pre>
+
**:: sudo make install               # you needed sudo (root) vs just running this as make install</pre>
  
  
−
Other readings:
+
==== Other readings ====
 +
 
 +
While researching this activity, these other resources were found. Instructors and students may find them useful for added reading or background.
 +
 
 +
* [http://dnf.readthedocs.org/en/latest/command_ref.html DNF Man Page]
 +
* https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Writing_a_package_from_scratch
 
* https://wiki.archlinux.org/index.php/Arch_User_Repository
 
* https://wiki.archlinux.org/index.php/Arch_User_Repository
 
* https://wiki.archlinux.org/index.php/Arch_packaging_standards
 
* https://wiki.archlinux.org/index.php/Arch_packaging_standards
−
* https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#Writing_a_package_from_scratch
+
* http://www.tecmint.com/command-line-tools-to-monitor-linux-performance/
  
  
−
Consider breaking these additional steps into a new activity
+
==== Consider breaking these additional steps into a new activity ====
−
# Have students host the package on a web source (ftp? Some free internet service that makes the .rpm accessible by URL)
+
 
 +
The following can be additional future steps, or a completely separate activity:
 +
# Have students host the package on a web source (A free internet service that makes the .rpm accessible by URL)
 
#* Package Repo location
 
#* Package Repo location
−
#**http://copr.fedorainfracloud.org - Use this for students to make their own packages and repositories
+
#** http://copr.fedorainfracloud.org - Use this for students to make their own packages and repositories
 
#** https://fedorahosted.org/copr/ - The actual community / project page where user manuals and developer resources exist
 
#** https://fedorahosted.org/copr/ - The actual community / project page where user manuals and developer resources exist
 
# Have each student in the class pair up and try to install the other person's RPM and run the new command
 
# Have each student in the class pair up and try to install the other person's RPM and run the new command
  
−
 
+
[[Category:Learning Activity]]
−
Ideas on what to create into an RPM:
+
[[Category:Coding and Style]]
−
* screen
+
[[Category:Product Packaging and Distribution]]
−
* htop
+
[[Category:Good Draft]]
−
* from http://www.tecmint.com/command-line-tools-to-monitor-linux-performance/
+

Latest revision as of 11:29, 6 August 2020


Title

Linux RPM package management Part 1 (Packaging the 'htop' command)

Overview

Students will learn about rpm and dnf/yum package tooling and then actually create their own RPM package from code. This can be advertised to students as being able to distribute their own Linux-based application to the world.

Prerequisites

Students should be familiar with:

  • Beginner to Intermediate Shell knowledge (Linux command line)
    • Getting around the Linux file system, sudo'ing, editing files, etc.
  • Making and compiling Linux software code
    • see extended note in the Comments section below
Learning
Objectives 		After successfully completing this activity, the learner should be able to:
  • Install RPM's and use the dnf/yum command to install and inspect packages
  • Create a compliant .spec file
  • Build an RPM from existing code and assure that it works
  • Keep a working log and cheat sheet of command-line history
Process Skills
Practiced


Background

Is there background reading material?

Are there other related activities?

What is the rationale for this activity?

  • Students may wonder how they can distribute Linux-based code that they develop out to other everyday users. Not many users enjoy compiling code, so the RPM package structure allows easy installation of binary pre-compiled code packages. Basically, a student could have coded a small sample command-line application and now they can send it to others easily. The other side of it is that students, as users of Linux, will be interfacing with RPM packages not of their making and it will be good to have an understanding of the backends of how this works. Students will interface with the dnf and yum commands even if simply using Linux for fun. Now, they can have knowledge into how it works and how they can employ it for their careers and personal uses.


Directions

Keep a working log

Log your shell commands, answers to questions, and commentary in a text file, wiki, or blog. You will be constructing and troubleshooting numerous Linux shell command's and their outputs. Your assignment is to document these commands and the process you went through in an organized fashion. You might use bullet points or a new set of commands on each line. Make sure it is easily consumable by a human (your instructor), as well as yourself 10 years from now.

The data that is the output of the commands is not as interesting as key lines or a summary/comment of their output or on what the command has done - ex: failed, succeeded, why, what it did, what it changed, etc. Write these in complete sentences. Commentary is especially important if you run into problems. When this occurs, state the problem and how you intend to solve it. At the end, you should have a text document with all of the commands, right and wrong, that you went through to get this activity completed. It should read as a timeline of what you did and what your thoughts were, to get the assignment complete. After this is complete, you will summarize the most useful commands into a sort of cheat sheet - this can come in useful for years to come.

See some samples and tools for a working log. Whatever method you use, make your written log human readable, make it a story if you wish. When you come back to this years from now, needing to remind yourself how to package some newly minted code, you want a summary/cheat sheet and you want to be able to understand the context and follow your thoughts of why you tried certain things. You don't want to be parsing through lines and lines of shell input and output.

Working log examples
Working log Tools to help you
  • history command - Use this command to see what commands you have typed in the past.
  • script command - You may alternately want to use the script command, which records all commands and their output to a file. The downside is that you have to remember to run this command before you wanted that output.
  • Multiple terminal windows/tabs - It is advised that you utilize multiple terminal (shell) windows at the same time. When you get sidetracked on installing a dependency, use a separate window for that. This keeps your shell history organized and parsable afterwards.
  • Up your terminals buffer limit - You might also consider upping your terminal windows buffer for the number of lines it holds, to somewhere in the tens of thousands - just in case you decide you want to come back to something you learned a while back, or in case a command spits out thousands of lines of results - which can happen. Some terminal applications can record commands and output to text files.


The activity will follow these general steps

  1. Use dnf/yum and rpm files.
  2. Learn about creating rpm's and the rpmbuild command.
  3. Package the htop project into an RPM.


Step 1: dnf / yum and .rpm's

  • First, lets do some learning before we jump into shell commands. Answer the following in your log:
    • What is the difference between dnf and yum? Why was the change made?
    • What are .rpm files? Where might you find them and how are they used?
  • Use the dnf command to view what packages have been recently installed on your machine.
    • Hint: There is a specific command for this. man dnf is your friend
    • Attempting to list all packages will often be quite a long listing.
  • Use the dnf command to install a .rpm package not currently installed on your machine.
    • Pick something simple, as you will need to operate it in the next steps.
    • Hint: If you dont find your own (more credit given for this), you can install screen
  • Use dnf to show that the new package is now installed.
  • Run or operate this newly installed utility. Where did dnf place the executable file?


Step 2: RPM's and rpmbuild

Required reading / watching:

  1. RPM Build Example Video - Watch, at least, the first 8 mins of this video from a recording of a local Linux User Group meeting
  2. RPM process Diagram from video - Find the diagram that the video references on the page labeled 12-17
    • Document authored by Guru Labs, L.C. released under the CC-BY-NC-ND 2.0 license
  3. Packaging the `wget` command - Review this example in its entirety
    • This will take some time to read, but don't worry about details, as we will step through it again below.
    • If you were to try to follow along in the shell, there may be some difficulties with wget.
    • Instead, save it for Part 3 below; You will use this readings structure to turn the htop code into an RPM.

Questions:

  • What is a source RPM vs binary RPM?
  • What does the rpmbuild command do?
  • Quickly summarize the directory structure when making your own RPM - you will stick this into your cheat sheet later, so make it short.


Step 3: Create your own 'htop' RPM

In this section, we will take code from the htop project and turn it into an RPM package.

Htop is a tool that shows you how busy your CPUs and memory are, as well as detailed information about the various processes being run on your operating system. It is semi visual, in that it runs in the terminal, but uses colors and blocks to make "graphics" (called ncurses). It is a successor to the famed top command that comes in all linux flavors. System administrators use both of these to diagnose and troubleshoot problems.

Htop was selected in this activity because it does not come standard in most operating systems, meaning it is not already installed. It is also a relatively small/simple build and the functionality of htop is rather useful.


Instructions:

  • Build htop manually
    • Compile the htop project to test that the code can be turned into binary form in your environment.
    • Before you can create an RPM, code must compile manually.
    • See Dependency Issues in the appendix below for detailed configure and make issues that you might run into.
    • Once you have ./configure, make, and make install compiling htop, you can move on to building an RPM for it
  • Create RPM dir structure
    • It should look like: 
       [nyeates@localhost myhtop]$ ls

       BUILD  RPMS  SOURCES  SPECS  SRPMS
    • Place your tar.gz file into the SOURCES directory
    • Assure that you stick to the naming convention "package-version.tar.gz"
  • Build an RPM and test that it works
    • Run rpmbuild command
    • Use rpmlint and mock to verify that the created .RPM works
    • (Optional) You might try to dnf install the RPM on a separate computer or shell to see that it really works
      • This is not required for this activity

Deliverables

One single text document can hold all of what needs to be handed in below. Put them in the following order, first to last, so that the instructor can find them easily.

Students will hand in:

  • Cheat sheet / Summary
    • A quick-reference guide, truly meant for your future use.
    • List key commands and what they do.
    • Succinctly explain the RPM directory structure.
  • Answers to specific questions
    • 1-3 sentance answers to the questions asked throughout the above activity.
  • The working log
    • See the above lengthy note about the working log.

Assessment

Criteria Level 1 (fail) Level 2 (pass) Level 3 (good) Level 4 (exceptional)
Installs and inspects RPMs with dnf/yum Did not attempt commands Attempted to install RPM, but was unsuccessful Installed RPM and showed that it is installed Installed RPM, showed that it is installed, and ran the installed binary
Creates a compliant .spec file Did not attempt to create file Creates file, but minimally fills out metadata Creates file, fills out metadata Creates file, fills out metadata, and adds comments
Builds an RPM and assures that it works Did not attempt to build RPM Attempted to build RPM, but was unsuccessful Built RPM Built RPM and assured that it works with rpmlint, mock and/or dnf install
Creates a working log and cheat sheet of commands Did not create a working log Created a minimal working log that shows only commands and their output - no user comments Created working log that explains commands and summarizes with a cheat sheet Created working log that contains an easy to follow narrative of commands and reasons why they were run; Summarizes with a cheat sheet that is very easy to reference and understand


Comments

What should the instructor know before using this activity?

  • Students should know how to compile Linux software code before doing this activity.
    • There exists an activity which covers this: Introduction_to_building_open_source_software
    • Particularly, students should have experience using the configure, make, and make install commands
    • If students have not compiled in the past, it is common to not have all of the required libraries and modules already installed for the compilation process to succeed. This is a major part of creating RPM's. This setup takes time to troubleshoot and setup, and it could be different on each system if students are not using identical operating systems.

What are some likely difficulties that an instructor may encounter using this activity?

  • Instructors may run into students having build problems. The instructor should implement the commands of this activity on a machine themselves. You may still run into student problems that you did not see, but at least you have the context.
  • If you allow students to run on their own systems, there may be more of these compatibility problems. Consider a lab / virtual machine environment or telling students that are on their own environments that they will need to support themselves.


Additional Information

ACM BoK
Area & Unit(s)

PL - Programming Languages, SE - Software Engineering

ACM BoK
Topic(s)

PL/Compiler Semantic Analysis, PL/Code Generation, SE/Tools and Environments

Difficulty

Easy-Medium, for students that meet the pre-reqs

Estimated Time
to Complete

3-4 hours

Environment /
Materials
  • Access to the shell of a Linux operating system that uses RPM (virtualized or on hardware can work)
  • root access is likely needed - another good vote for virtualized systems (might use virtualbox)
Author(s)

Nick Yeates

Source
License

This work is licensed under a Creative Commons Attribution 4.0 International License

CC-BY.png


Suggestions for Open Source Community

Suggestions for an open source community member who is working in conjunction with the instructor:

  • Why did your community decide to standardize on the autotools-based config/make building? Or, why not?
  • Explain to students why packaging skills can be used on many open source linux-based projects, across their careers.
  • Help students through the often-confusing build process
  • Help students to find alternate examples to step through - aka, finding project code other than the ones listed above and making it into an RPM.

Appendix

Dependency Issues

  • htop may provide you with issues when running ./configure, make, and make install; Find some solutions below.
    • There is always some odd ./configure setting or dependency that needs installing (this means, other rpm packages that this project needs installed in order to compile)
    • Unfortunately, these dependencies are not installed automatically - you must install them yourself and then try to ./configure or make again
  • Some dependency issues you might run into with htop:
    • gcc, try each of these commands one at a time: 
       sudo dnf install glibc-devel glibc-headers kernel-headers kernel-devel gnutls-devel

       sudo dnf groupinstall "Development Tools"

       sudo dnf install gnutls

       # answer from http://stackoverflow.com/questions/18076157/why-does-configure-say-no-c-compiler-found-when-gcc-is-installed
    • libncurses or unicode, "configure: error: You may want to use --disable-unicode or install libncursesw." 
       ./configure --disable-unicode   # first try disabling unicode like they suggest

       which ncurses                   # ncurses is usually already installed, but if not, you will need to dnf install it also

       sudo dnf install ncurses-devel  # try installing the ncurses-developer library package

       # answer from http://www.linuxquestions.org/questions/linux-software-2/error-while-try-to-install-htop-0-8-a-655823/
  • Some make issues you might run into with htop:
    • Permission denied, "/usr/bin/install: cannot create regular file '/usr/local/bin/htop': Permission denied" 
       sudo make install               # you needed sudo (root) vs just running this as make install


Other readings

While researching this activity, these other resources were found. Instructors and students may find them useful for added reading or background.


Consider breaking these additional steps into a new activity

The following can be additional future steps, or a completely separate activity:

  1. Have students host the package on a web source (A free internet service that makes the .rpm accessible by URL)
  2. Have each student in the class pair up and try to install the other person's RPM and run the new command
Retrieved from "http://foss2serve.org/index.php?title=Linux_Package_Management_(Distribute_Your_App)&oldid=13763"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox