Author Topic: using chroot'ed environment for packaging  (Read 261 times)

Offline AnotherUser

  • Full Member
  • ***
  • Posts: 93
using chroot'ed environment for packaging
« on: January 14, 2013, 08:16:19 PM »
Based on what I can find, it looks like the preferred RPM building environment for PCLOS is
  • Get a VirtualBox (or other VM)
  • Install into it some recent minimalistic PCLOS ISO
  • Update the install
  • Install pkgutils
  • Run the mkrepo script

It seems to me that all of these steps can be combined into a single step of creating a tar ball of an "installed system", and then reusing it as many times as you want by simply extracting it and chroot'ing into it to do the RPM building. Has anyone done that? Are there any down sides to doing this?

Offline sling-shot

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 1758
  • Satyameva Jayate | Truth Alone Triumphs.
Re: using chroot'ed environment for packaging
« Reply #1 on: January 14, 2013, 09:08:59 PM »
I have no idea of workings of a chroot setup. Our regular experienced packagers should be along soon with an answer.

With VirtualBox however I am able to save copies of the setup at various points of time and easily rollback as needed. I am also able to package in one environment and test in another and continue other work in the host. Only for final testing of built packages and those which interact with hardware directly, I use a separate partition after a reboot.
Packaging well will cure headaches of many :) But learning to package will cause headaches in many :(

AMD AthlonX2 3600+/ASUS M2NPV-VM/ATi HD4670/Onboard sound/3.5GB DDR2-533 RAM/SEAGATE 160+320GB HDD/DELL S2240L FullHD/Creative SBS370 2.1/PCLinuxOS2013/KDE4
Samsung NP305U1-A06IN | Nokia E6

Offline kjpetrie

  • PCLinuxOS Tester
  • Hero Member
  • *******
  • Posts: 4037
Re: using chroot'ed environment for packaging
« Reply #2 on: January 27, 2013, 09:17:29 AM »
It sounds plausible, but you couldn't keep reusing the same tarball, because it would have to be kept upgraded and rearchived. You could use squashfs as an alternative to tar, but I expect the frequent unpacking, upgrading and repacking would become just as tedious as any other method. You would also have to ensure it had the right modules for your running kernel, as unlike a VM, it wouldn't have its own kernel. Would have to be the same arch as your main system too, so you'd still need a machine of the other arch.
-----------
KJP
-----------------------------------------------------------
PClos64 RC1 on Intel D945GCLF2 motherboard (Atom 330), 2GB DDR2 RAM, Maxtor STM325031, HL-DT-ST DVDRAM GSA-H42N, Amilo LSL 3220T monitor. Also Acer 5810TG (with custom kernel) and Asus eeePC 2G surf