\section{Why Use Packages?}
\begin{frame}
   {Why Use Packages?}

   \begin{itemize}
      \item Automation: No need for manual installs and upgrades
      \item Scalability: Install packages on one system, or
      10,000 systems
      \item Repeatability and predictability
      \item Security and auditing
   \end{itemize}

\end{frame}

\cprotect\note {

   Software package management systems are widely seen as
   one of the biggest advancements \textbf{Linux} brought
   to enterprise IT environments. By keeping track of files
   and metadata in an automated, predictable and reliable
   way, system administrators can use package management
   systems to make their installation processes scale to
   thousands of systems without requiring manual work on
   each individual system.  }

\section{Software Packaging Concepts}

\begin{frame}
   {Software Packaging Concepts}

   \begin{itemize}
      \item Gather and compress associated software files into a
      single package (archive), which may require
      other packages to be installed first
      \item Allow for easy software installation or removal
      \item Can verify file integrity via an internal database
      \item Can authenticate the origin of packages
      \item Facilitate upgrades
      \item Group packages by logical features
      \item Manage dependencies between packages
   \end{itemize}

\end{frame}

\cprotect\note {

   \textbf{Package management systems} supply the tools
   that allow system administrators to automate installing,
   upgrading, configuring and removing software packages in
   a known, predictable and consistent manner.

   A given package may contain executable files, data
   files, documentation, installation scripts and
   configuration files.  Also included are
   \textbf{metadata} attributes such as version numbers,
   checksums, vendor information, dependencies,
   descriptions, etc.

   Upon installation, all that information is stored
   locally into an internal database which can be
   conveniently queried for version status and update
   information.

}

\section{Package Types}
\begin{frame}
   {Package Types}

   \begin{itemize}
      \item \textbf{Binary} packages contain files ready for
      deployment, including executable files and libraries.
      These are architecture dependent.
      \item \textbf{Source} packages are used to generate binary
      packages; one should always be able to rebuild a binary
      package from the source package. One source package can
      be used for multiple architectures.
      \item \textbf{Architecture-independent} packages contain
      files and scripts that run under script interpreters, as
      well as documentation and configuration files.
      \item \textbf{Meta-packages} are groups of associated
      packages that collect everything needed to install a
      relatively large subsystem, such as a desktop
      environment, or an office suite etc.
   \end{itemize}

\end{frame}

\cprotect\note {

   Binary packages are the ones that system administrators
   have to deal with most of the time.  On 64-bit systems
   that can run 32-bit programs, one may have two binary
   packages installed for a given program, perhaps one with
   \textbf{x86\_64} or \textbf{amd64} in its name, and the
   other with \textbf{i386} or \textbf{i686} in its name.

   Source packages can be helpful in keeping track of
   changes and source code used to come up with binary
   packages. They are usually not installed on a system by
   default but can always be retrieved from the vendor.

   It should always be possible to rebuild binary packages
   from their source packages; for example on \textbf{RPM}-based
   systems one can rebuild the \textbf{p7zip} binary package
   by doing:

   \begin{cmd}
# rpmbuild --rebuild -rb p7zip-16.02-16.el8.src.rpm
   \end{cmd}
   which will place the results in \filelink{/root/rpmbuild}:
   \begin{cmd}
# root/rpmbuild>find . -name "*rpm"
   \end{cmd}
   \begin{response}
./RPMS/x86_64/p7zip-plugins-16.02-16.el8.x86_64.rpm
./RPMS/x86_64/p7zip-debugsource-16.02-16.el8.x86_64.rpm
./RPMS/x86_64/p7zip-plugins-debuginfo-16.02-16.el8.x86_64.rpm
./RPMS/x86_64/p7zip-16.02-16.el8.x86_64.rpm
./RPMS/noarch/p7zip-doc-16.02-16.el8.noarch.rpm
   \end{response}
   with the exact location depending on the \textbf{Linux}
   distribution and version.
}


\section{Available Package Management Systems}
\begin{frame}
   {Available Package Management Systems}

   \begin{figure}[H]
      \includegraphics[height=.6in]{IMAGES/RPM_Logo}\hspace{.33in}
      \includegraphics[height=.6in]{IMAGES/apt}
      \caption{RPM and APT}
   \end{figure}


   Two very common package management systems:
   \begin{itemize}

      \item \textbf{RPM} (\textbf{Red Hat Package Manager})

      Used by all \textbf{Red Hat}-derived distributions, such
      as \textbf{Red Hat Enterprise Linux}, \textbf{Fedora},
      \textbf{CentOS}, as well as
      by \textbf{SUSE} and its related community
      \textbf{openSUSE} distribution.

      \item \textbf{dpkg} (\textbf{Debian Package})

      Used by all \textbf{Debian}-derived distributions
      including \textbf{Debian}, \textbf{Ubuntu} and
      \textbf{Linux Mint}.

   \end{itemize}

\end{frame}

\cprotect\note{

   There are other package management systems, such as
   \textbf{portage/emerge} used by \textbf{Gentoo},
   \textbf{pacman} used by \textbf{Arch}, and specialized
   ones used by \textbf{Embedded Linux} systems and
   \textbf{Android}.

   Another ancient system is just to supply packages as
   \textbf{tarballs} without any real management or clean
   removal strategies; this approach still marks
   \textbf{Slackware}, one of the oldest \textbf{Linux}
   distributions.

   But most of the time it is either \textbf{RPM} or
   \textbf{dpkg} and these are the only ones we will
   consider in this course.

}

\section{Packaging Tool Levels and Varieties}
\begin{frame}
   {Packaging Tool Levels and Varieties}

   \begin{itemize}

      \item \textbf{Low Level Utility}:

      Install or remove a single package or a list of named ones
      \begin{itemize}
         \item Dependencies not fully handled, only warned about or cause error
         \item If another package needs to be installed first
         installation will fail
         \item If the package is needed by another package,
         removal will fail
      \end{itemize}
      \item Examples: \textbf{rpm} and \textbf{dpkg}

      \item \textbf{High Level Utility}

      Solves the dependency problems:
      \begin{itemize}
         \item
         Will install any other packages required
         \item
         Will avoid conflicts with already installed packages
      \end{itemize}
      \item Examples: \textbf{dnf}, \textbf{yum},
      \textbf{zypper}, \textbf{PackageKit},and
      \textbf{apt}

   \end{itemize}

\end{frame}

\cprotect\note {

   There are two levels to packaging systems:
   \begin{enumerate}

      \item \textbf{Low Level Utility}: This simply installs or
      removes a single package, or a list of packages each
      one of which is individually and specifically named.
      Dependencies are not fully handled, only warned about or
      produce an error
      \begin{itemize}
         \item If another package needs to be installed first
         installation will fail.
         \item If the package is needed by another package,
         removal will fail.
      \end{itemize} The \textbf{rpm} and \textbf{dpkg} utilities
      play this role for the packaging systems that use them.

      \item \textbf{High Level Utility}: This solves the
      dependency problems:
      \begin{itemize}
         \item If another package or group of packages needs to
         be installed before software can be installed, such
         needs will be satisfied.
         \item If removing a package interferes with another
         installed package, the administrator will be given
         the choice of either aborting, or removing all
         affected software.
      \end{itemize} The \textbf{dnf} and \textbf{zypper}
      utilities (and the older \textbf{yum}) take
      care of the dependency resolution for \textbf{rpm}
      systems, and \textbf{apt-get} and \textbf{apt-cache} and
      other utilities take care of it for \textbf{dpkg}
      systems.
   \end{enumerate}


   In this course we will only discuss the command line
   interfaces to the packaging management systems; while the
   graphical front ends used by each \textbf{Linux} distribution can be
   useful, we would like to be less tied to any one interface
   and have more flexibility.

}

\section{Package Sources}
\begin{frame}
   {Package Sources}

   \begin{itemize}
      \item Distributions have multiple \textbf{repositories}
      \item All packages must work together well
      \item External repositories also exist; some interface
      cleanly, others cause conflicts
   \end{itemize}

\end{frame}

\cprotect\note{

   Every distribution has one or more package
   \textbf{repositories} where system utilities go to
   obtain software and to update with new versions.  It is
   the job of the distribution to make sure all packages in
   the repositories play well with each other.

   There are always other, external repositories, which can
   be added to the standard distribution-supported list.
   Sometimes these are closely associated with the
   distribution and only rarely produce significant
   problems; an example would be the \textbf{EPEL}
   (\textbf{E}xtra \textbf{P}ackages for
   \textbf{E}nterprise \textbf{L}inux) set of
   version-dependent repositories, which fit well with
   \textbf{RHEL} since their source is \textbf{Fedora} and
   the maintainers are close to \textbf{Red Hat}.

   However, some external repositories are not very well
   constructed or maintained. For example, when a package
   is updated in the main repository, dependent packages
   may not be updated in the external one, which can lead
   to one form of \textbf{dependency hell}.

}

\section{Creating Software Packages}
\begin{frame}
   {Creating Software Packages}

   \begin{itemize}
      \item Create easy to install packages for custom software
      \item Packages allow for additional tasks to be performed
      during install
      \begin{itemize}
         \item Creating needed symbolic links
         \item Creating directories as needed
         \item Setting permissions
         \item Anything that can be scripted
      \end{itemize}
      \item Many formats available
      \begin{itemize}
         \item \textbf{RPM} for \textbf{Red Hat} and \textbf{SUSE}-based systems
         \item \textbf{DEB} for \textbf{Debian} for \textbf{Debian}-based systems
         \item \textbf{TGZ} for \textbf{Slackware}
         \item \textbf{APK} for \textbf{Android}
      \end{itemize}
   \end{itemize}

\end{frame}

\cprotect\note{

   Building your own custom software packages makes it easy
   to distribute and install your own software.  Almost
   every version of \textbf{Linux} has some mechanism for
   doing this.

   Building your own software software allows you to
   control exactly what goes in the software and exactly
   how it is installed.  You can create the package so that
   installing it runs scripts that perform all tasks needed
   to install the new software and/or remove the old
   software.

}

