RPM Packaging How software delivery works and why RPM packaging is - - PowerPoint PPT Presentation

▶
rpm packaging
SMART_READER_LITE
LIVE PREVIEW

RPM Packaging How software delivery works and why RPM packaging is - - PowerPoint PPT Presentation

Oct 14, 2023 166 likes •1.06k views

RPM Packaging How software delivery works and why RPM packaging is more current than ever Fabio Alessandro Locati 26 October 2016 Outline Intro Deployments RPM Processes RPM and Docker 1 Intro About me RPM user since 2001 IT

slide-1
SLIDE 1

RPM Packaging

How software delivery works and why RPM packaging is more current than ever

Fabio Alessandro Locati 26 October 2016

slide-2
SLIDE 2

Outline

Intro Deployments RPM Processes RPM and Docker

1

slide-3
SLIDE 3

Intro

slide-4
SLIDE 4

About me

  • RPM user since 2001
  • IT Consultant since 2004
  • RPMs creator since 2013

2

slide-5
SLIDE 5

About me

  • RPM user since 2001
  • IT Consultant since 2004
  • RPMs creator since 2013

2

slide-6
SLIDE 6

About me

  • RPM user since 2001
  • IT Consultant since 2004
  • RPMs creator since 2013

2

slide-7
SLIDE 7

About me

  • RPM user since 2001
  • IT Consultant since 2004
  • RPMs creator since 2013

2

slide-8
SLIDE 8

Deployment in the past

  • Mayority of application needed to be deployed on a single system
  • Annual/Bi-annual
  • All hands on deck
  • Devs ready to patch
  • Ops ready to deploy work-around
  • Usually performed during night-time
  • Hours of downtime
  • Very expensive deployments

3

slide-9
SLIDE 9

Deployment in the past

  • Mayority of application needed to be deployed on a single system
  • Annual/Bi-annual
  • All hands on deck
  • Devs ready to patch
  • Ops ready to deploy work-around
  • Usually performed during night-time
  • Hours of downtime
  • Very expensive deployments

3

slide-10
SLIDE 10

Deployment in the past

  • Mayority of application needed to be deployed on a single system
  • Annual/Bi-annual
  • All hands on deck
  • Devs ready to patch
  • Ops ready to deploy work-around
  • Usually performed during night-time
  • Hours of downtime
  • Very expensive deployments

3

slide-11
SLIDE 11

Deployment in the past

  • Mayority of application needed to be deployed on a single system
  • Annual/Bi-annual
  • All hands on deck
  • Devs ready to patch
  • Ops ready to deploy work-around
  • Usually performed during night-time
  • Hours of downtime
  • Very expensive deployments

3

slide-12
SLIDE 12

Deployment in the past

  • Mayority of application needed to be deployed on a single system
  • Annual/Bi-annual
  • All hands on deck
  • Devs ready to patch
  • Ops ready to deploy work-around
  • Usually performed during night-time
  • Hours of downtime
  • Very expensive deployments

3

slide-13
SLIDE 13

Deployment in the past

  • Mayority of application needed to be deployed on a single system
  • Annual/Bi-annual
  • All hands on deck
  • Devs ready to patch
  • Ops ready to deploy work-around
  • Usually performed during night-time
  • Hours of downtime
  • Very expensive deployments

3

slide-14
SLIDE 14

Deployment in the past

  • Mayority of application needed to be deployed on a single system
  • Annual/Bi-annual
  • All hands on deck
  • Devs ready to patch
  • Ops ready to deploy work-around
  • Usually performed during night-time
  • Hours of downtime
  • Very expensive deployments

3

slide-15
SLIDE 15

Deployment in the past

  • Mayority of application needed to be deployed on a single system
  • Annual/Bi-annual
  • All hands on deck
  • Devs ready to patch
  • Ops ready to deploy work-around
  • Usually performed during night-time
  • Hours of downtime
  • Very expensive deployments

3

slide-16
SLIDE 16

Deployment in the past

  • Mayority of application needed to be deployed on a single system
  • Annual/Bi-annual
  • All hands on deck
  • Devs ready to patch
  • Ops ready to deploy work-around
  • Usually performed during night-time
  • Hours of downtime
  • Very expensive deployments

3

slide-17
SLIDE 17

Today expectations

  • Deploy multiple times every day
  • Cheap deployments
  • No down time
  • Need of mass deployment (tens/hundreds/thousands of systems)
  • Horizontal (dynamic) scalability

4

slide-18
SLIDE 18

Today expectations

  • Deploy multiple times every day
  • Cheap deployments
  • No down time
  • Need of mass deployment (tens/hundreds/thousands of systems)
  • Horizontal (dynamic) scalability

4

slide-19
SLIDE 19

Today expectations

  • Deploy multiple times every day
  • Cheap deployments
  • No down time
  • Need of mass deployment (tens/hundreds/thousands of systems)
  • Horizontal (dynamic) scalability

4

slide-20
SLIDE 20

Today expectations

  • Deploy multiple times every day
  • Cheap deployments
  • No down time
  • Need of mass deployment (tens/hundreds/thousands of systems)
  • Horizontal (dynamic) scalability

4

slide-21
SLIDE 21

Today expectations

  • Deploy multiple times every day
  • Cheap deployments
  • No down time
  • Need of mass deployment (tens/hundreds/thousands of systems)
  • Horizontal (dynamic) scalability

4

slide-22
SLIDE 22

Today expectations

  • Deploy multiple times every day
  • Cheap deployments
  • No down time
  • Need of mass deployment (tens/hundreds/thousands of systems)
  • Horizontal (dynamic) scalability

4

slide-23
SLIDE 23

Deployments

slide-24
SLIDE 24

Items that could be involved in deployments

  • Code
  • Source Control System (SCM): git, hg, svn, cvs
  • Build system: Koji, Jenkins, Shell
  • Software packaging system: RPM, DEB, Docker, WAR, generic archive
  • Test system: Bodhi, Jenkins
  • Environment packaging system: Docker, PyEnv
  • Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
  • Execution environment: Native OS, OpenStack, OpenShift, Docker, runc

5

slide-25
SLIDE 25

Items that could be involved in deployments

  • Code
  • Source Control System (SCM): git, hg, svn, cvs
  • Build system: Koji, Jenkins, Shell
  • Software packaging system: RPM, DEB, Docker, WAR, generic archive
  • Test system: Bodhi, Jenkins
  • Environment packaging system: Docker, PyEnv
  • Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
  • Execution environment: Native OS, OpenStack, OpenShift, Docker, runc

5

slide-26
SLIDE 26

Items that could be involved in deployments

  • Code
  • Source Control System (SCM): git, hg, svn, cvs
  • Build system: Koji, Jenkins, Shell
  • Software packaging system: RPM, DEB, Docker, WAR, generic archive
  • Test system: Bodhi, Jenkins
  • Environment packaging system: Docker, PyEnv
  • Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
  • Execution environment: Native OS, OpenStack, OpenShift, Docker, runc

5

slide-27
SLIDE 27

Items that could be involved in deployments

  • Code
  • Source Control System (SCM): git, hg, svn, cvs
  • Build system: Koji, Jenkins, Shell
  • Software packaging system: RPM, DEB, Docker, WAR, generic archive
  • Test system: Bodhi, Jenkins
  • Environment packaging system: Docker, PyEnv
  • Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
  • Execution environment: Native OS, OpenStack, OpenShift, Docker, runc

5

slide-28
SLIDE 28

Items that could be involved in deployments

  • Code
  • Source Control System (SCM): git, hg, svn, cvs
  • Build system: Koji, Jenkins, Shell
  • Software packaging system: RPM, DEB, Docker, WAR, generic archive
  • Test system: Bodhi, Jenkins
  • Environment packaging system: Docker, PyEnv
  • Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
  • Execution environment: Native OS, OpenStack, OpenShift, Docker, runc

5

slide-29
SLIDE 29

Items that could be involved in deployments

  • Code
  • Source Control System (SCM): git, hg, svn, cvs
  • Build system: Koji, Jenkins, Shell
  • Software packaging system: RPM, DEB, Docker, WAR, generic archive
  • Test system: Bodhi, Jenkins
  • Environment packaging system: Docker, PyEnv
  • Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
  • Execution environment: Native OS, OpenStack, OpenShift, Docker, runc

5

slide-30
SLIDE 30

Items that could be involved in deployments

  • Code
  • Source Control System (SCM): git, hg, svn, cvs
  • Build system: Koji, Jenkins, Shell
  • Software packaging system: RPM, DEB, Docker, WAR, generic archive
  • Test system: Bodhi, Jenkins
  • Environment packaging system: Docker, PyEnv
  • Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
  • Execution environment: Native OS, OpenStack, OpenShift, Docker, runc

5

slide-31
SLIDE 31

Items that could be involved in deployments

  • Code
  • Source Control System (SCM): git, hg, svn, cvs
  • Build system: Koji, Jenkins, Shell
  • Software packaging system: RPM, DEB, Docker, WAR, generic archive
  • Test system: Bodhi, Jenkins
  • Environment packaging system: Docker, PyEnv
  • Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
  • Execution environment: Native OS, OpenStack, OpenShift, Docker, runc

5

slide-32
SLIDE 32

Items that could be involved in deployments

  • Code
  • Source Control System (SCM): git, hg, svn, cvs
  • Build system: Koji, Jenkins, Shell
  • Software packaging system: RPM, DEB, Docker, WAR, generic archive
  • Test system: Bodhi, Jenkins
  • Environment packaging system: Docker, PyEnv
  • Orchestration tool: Ansible, Puppet, Salt, Chef, Kubernetes
  • Execution environment: Native OS, OpenStack, OpenShift, Docker, runc

5

slide-33
SLIDE 33

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-34
SLIDE 34

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-35
SLIDE 35

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-36
SLIDE 36

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-37
SLIDE 37

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-38
SLIDE 38

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-39
SLIDE 39

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-40
SLIDE 40

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-41
SLIDE 41

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-42
SLIDE 42

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-43
SLIDE 43

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-44
SLIDE 44

RPM as software packaging system

  • Advantages
  • Very well known format
  • Open Standard
  • Clear distinction between compile environment and run environment
  • Easy to integrate with any kind of environment
  • Very good at resolving dependencies
  • Checksum of all files
  • Very rigid policies
  • Disadvantages
  • Heavily connected with RPM-based distro (Fedora, RHEL, OEL, SLES, OpenSUSE,

CentOS, SL)

  • Very rigid policies

6

slide-45
SLIDE 45

RPM components

  • SPEC file
  • Sources files (at least 1)
  • Patches (eventually)

7

slide-46
SLIDE 46

RPM components

  • SPEC file
  • Sources files (at least 1)
  • Patches (eventually)

7

slide-47
SLIDE 47

RPM components

  • SPEC file
  • Sources files (at least 1)
  • Patches (eventually)

7

slide-48
SLIDE 48

RPM components

  • SPEC file
  • Sources files (at least 1)
  • Patches (eventually)

7

slide-49
SLIDE 49

RPM Processes

slide-50
SLIDE 50

RPM build process

  • Fetch of the SPEC file
  • Fetch of sources/patches
  • Creation of the .src.rpm file
  • Creation of binaries .rpm files

8

slide-51
SLIDE 51

RPM build process

  • Fetch of the SPEC file
  • Fetch of sources/patches
  • Creation of the .src.rpm file
  • Creation of binaries .rpm files

8

slide-52
SLIDE 52

RPM build process

  • Fetch of the SPEC file
  • Fetch of sources/patches
  • Creation of the .src.rpm file
  • Creation of binaries .rpm files

8

slide-53
SLIDE 53

RPM build process

  • Fetch of the SPEC file
  • Fetch of sources/patches
  • Creation of the .src.rpm file
  • Creation of binaries .rpm files

8

slide-54
SLIDE 54

RPM build process

  • Fetch of the SPEC file
  • Fetch of sources/patches
  • Creation of the .src.rpm file
  • Creation of binaries .rpm files

8

slide-55
SLIDE 55

Fedora pipeline

  • SPEC file, additional sources, and patches in git repo
  • Upstream source in cache system
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch

9

slide-56
SLIDE 56

Fedora pipeline

  • SPEC file, additional sources, and patches in git repo
  • Upstream source in cache system
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch

9

slide-57
SLIDE 57

Fedora pipeline

  • SPEC file, additional sources, and patches in git repo
  • Upstream source in cache system
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch

9

slide-58
SLIDE 58

Fedora pipeline

  • SPEC file, additional sources, and patches in git repo
  • Upstream source in cache system
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch

9

slide-59
SLIDE 59

Fedora pipeline

  • SPEC file, additional sources, and patches in git repo
  • Upstream source in cache system
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch

9

slide-60
SLIDE 60

Fedora pipeline

  • SPEC file, additional sources, and patches in git repo
  • Upstream source in cache system
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch

9

slide-61
SLIDE 61

Fedora pipeline

  • SPEC file, additional sources, and patches in git repo
  • Upstream source in cache system
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch

9

slide-62
SLIDE 62

Fedora pipeline

  • SPEC file, additional sources, and patches in git repo
  • Upstream source in cache system
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch

9

slide-63
SLIDE 63

Example RPM pipeline 1

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch
  • Simple upgrade of live system (yum update -y PACKAGE)

10

slide-64
SLIDE 64

Example RPM pipeline 1

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch
  • Simple upgrade of live system (yum update -y PACKAGE)

10

slide-65
SLIDE 65

Example RPM pipeline 1

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch
  • Simple upgrade of live system (yum update -y PACKAGE)

10

slide-66
SLIDE 66

Example RPM pipeline 1

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch
  • Simple upgrade of live system (yum update -y PACKAGE)

10

slide-67
SLIDE 67

Example RPM pipeline 1

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch
  • Simple upgrade of live system (yum update -y PACKAGE)

10

slide-68
SLIDE 68

Example RPM pipeline 1

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch
  • Simple upgrade of live system (yum update -y PACKAGE)

10

slide-69
SLIDE 69

Example RPM pipeline 1

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch
  • Simple upgrade of live system (yum update -y PACKAGE)

10

slide-70
SLIDE 70

Example RPM pipeline 1

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Promotion to Bodhi testing branch
  • Automated tests by Bodhi and AutoQA
  • Manual testing
  • Promotion to Bodhi stable branch
  • Simple upgrade of live system (yum update -y PACKAGE)

10

slide-71
SLIDE 71

Example RPM pipeline 2

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Creation of a Docker image
  • Automated tests
  • Manual testing
  • Propagate the new Docker image

11

slide-72
SLIDE 72

Example RPM pipeline 2

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Creation of a Docker image
  • Automated tests
  • Manual testing
  • Propagate the new Docker image

11

slide-73
SLIDE 73

Example RPM pipeline 2

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Creation of a Docker image
  • Automated tests
  • Manual testing
  • Propagate the new Docker image

11

slide-74
SLIDE 74

Example RPM pipeline 2

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Creation of a Docker image
  • Automated tests
  • Manual testing
  • Propagate the new Docker image

11

slide-75
SLIDE 75

Example RPM pipeline 2

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Creation of a Docker image
  • Automated tests
  • Manual testing
  • Propagate the new Docker image

11

slide-76
SLIDE 76

Example RPM pipeline 2

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Creation of a Docker image
  • Automated tests
  • Manual testing
  • Propagate the new Docker image

11

slide-77
SLIDE 77

Example RPM pipeline 2

  • SPEC file, additional sources, and patches in git repo
  • Build in Koji
  • Creation of a Docker image
  • Automated tests
  • Manual testing
  • Propagate the new Docker image

11

slide-78
SLIDE 78

RPM and Docker

slide-79
SLIDE 79

RPM and Docker

  • RPM work very well in Docker environments
  • Installing RPMs allow a cleaner Docker file and image
  • RPMs can be deployed within or without Docker

12

slide-80
SLIDE 80

RPM and Docker

  • RPM work very well in Docker environments
  • Installing RPMs allow a cleaner Docker file and image
  • RPMs can be deployed within or without Docker

12

slide-81
SLIDE 81

RPM and Docker

  • RPM work very well in Docker environments
  • Installing RPMs allow a cleaner Docker file and image
  • RPMs can be deployed within or without Docker

12

slide-82
SLIDE 82

RPM and Docker

  • RPM work very well in Docker environments
  • Installing RPMs allow a cleaner Docker file and image
  • RPMs can be deployed within or without Docker

12

slide-83
SLIDE 83

Docker example

RUN dnf install -y tar make gcc ruby ruby-devel rubygems graphviz \ rubygem-nokogiri unzip findutils which wget python-devel \ zlib-devel libjpeg-devel redhat-rpm-config patch \ && dnf clean packages \ && gem install --no-ri --no-rdoc asciidoctor --version \ $ASCIIDOCTOR_VERSION \ && gem install --no-ri --no-rdoc asciidoctor-pdf --version \ 1.5.0.alpha.11 \ && gem install --no-ri --no-rdoc slim \ && (curl -LkSs https://api.github.com/repos/asciidoctor \ | tar xfz - -C $BACKENDS --strip-components=1) \ && wget https://bitbucket.org/pypa/setuptools/raw/bootstrap \

  • O - | python \

&& easy_install actdiag

13

slide-84
SLIDE 84

Docker example with RPM

RUN dnf install -y rubygem-asciidoctor-pdf \ && dnf clean packages

14

slide-85
SLIDE 85

Size of the images

  • Fedora base image: 204MB
  • First image: 776MB
  • Second image: 238MB

15

slide-86
SLIDE 86

Size of the images

  • Fedora base image: 204MB
  • First image: 776MB
  • Second image: 238MB

15

slide-87
SLIDE 87

Size of the images

  • Fedora base image: 204MB
  • First image: 776MB
  • Second image: 238MB

15

slide-88
SLIDE 88

Additional resources

  • Laboratorio ICT, 14:00 - Come pacchettizzare applicazioni in formato RPM
  • Slides: https://slides.fale.io/20161026-en-rpm.pdf
  • Official website: http://rpm.org
  • Fedora guide:

https://fedoraproject.org/wiki/How_to_create_an_RPM_package

  • RPM Guide: http://rpm-guide.readthedocs.io

16