Summary of details, decisions & dilemmas relating to basic port of LCFG to Debian

To start with, followed instructions in "Bootstrapping an LCFG Installation" (Appendix A of the SAGE booklet "LCFG: A Practical Tool for System Configuration"):

  • downloaded core lcfg packages (RPMs), and converted .rpm files to .deb with 'alien', but the results were not really workable.
  • experimented with the rpm "RPM for Debian" utility, but this didn't seem like the way to go either.
  • decided to start from scratch and download source from SVN repository ("If there are no prebuilt packages for your platform, the source can be downloaded from the CVS links on the Web site.")
  • once svn was installed, and sources downloaded & unpacked, tried building lcfg-utils... but this failed (no lcfg.cmake file)
  • lcfg.make is from LCFG Build Tools, so decided to install Build Tools (by following instructions on http://www.lcfg.org/doc/buildtools/install.html)
    (Maybe should have tried installing Build Tools first?)
  • tried building Build Tools, but one perl module missing (MooseX::App::Cmd) and install attempts failed - also warned that several other files were missing (which should, presumably, be generated from the .in versions, which do exist). Didn't manage to get this to work.
  • started from scratch again, using lcfg-reltool to create tarballs and then unpacked and built on Debian
  • installed lcfg-client-2.2.37 first - unpacked & built (using cmake, and other utils from Debian build-essential package).
  • built remaining source tarballs on DICE for LCFG Core packages (some with "lcfg-reltool pack", some with "lcfg-reltool devpack")
  • installed LCFG Core packages on Debian
    • noticed path discrepancy for liblcfg_pkgtools.so install (/usr/local/lib assumed by install process, /usr/lib assumed by Debian). Reported as LCFG Bug#190.
  • installed additional (prerequisite) Perl packages (see http://www.lcfg.org/download/current/sl5)
  • briefly investigated start-up process (init & inittab), but reconfiguring /etc/inittab to start client & file components didn't seem trivial - will revisit later)
  • created temporary /bin/domainname link (it's /bin/dnsdomainname under Debian), as boot component uses this (will need to be modified?)
  • created simple profile, compiled on LCFG server, and copied to Debian box using client component
  • added component resources to profile, corrected permissions on "om", and installed perl-suid module to allow om to run. Reported as LCFG Bug#194.
  • started client component via om
  • created simple OS headers, debian5.h & debian5vars.h, with versions in core/include/lcfg/os & core/include/inf/os
  • tested other basic components (file, logserver, & ngeneric)
  • fixed rungroup by adding conditional (re)definition to lcfg/defaults/profile.h
  • ported & investigated boot component (not yet in use)
  • ported & investigated init component (not yet in use)
    • noticed sxprof path discrepancy (hardwired as /usr/bin/sxprof in component, but installed in /usr/local/bin). Reported as LCFG Bug#195.
  • investigated package management tools (dpkg, apt-get, aptitude, dselect, &c)
  • investigated Debian package building (compared .deb & .rpm formats)
  • installed lintian & fakeroot packages (package building tools)
  • test package-build using dpkg and built lcfg_client-2.2.37.deb
    (although it had been pointed out that there may be a package-naming conflict for mkxprof - may need to adapt Translate method of updaterpms-equivalent component?)
    • need to investigate further pre/post scripts & permissions/ownership settings
  • copied updaterpms component across & configured for Debian environment
    (kept "updaterpms" name for now/testing, to circumvent default resource problems prior to full installation)
  • investigated updaterpms binary (took a look at source to see what it actually did)
  • investigate package list generation & format
    • generate list in core/packages/lcfg/lcfg_deb_lcfg.pkgs?
    • source packages in /afs/inf.ed.ac.uk/pkgs/debs?
  • need to decide what Debian equivalent of /usr/sbin/updaterpms should do

w/c 16.Nov.09

  • investigated APIs available for perl, python, &c (limited number for perl, more for python)
  • confirmed that "dpkg -i <package>.deb" does handle dependencies (fails without installing if dependencies not satisfied, unless "--ignore-depends" is used)
  • given paucity of perl APIs, and unfamiliarity with python,experimented with mock-up of script in bash

w/c 23.Nov.09

  • experimentation with bash script highlighted differences between rpm tools under RedHat and dpkg suite under Debian - maybe forcing dpkg into the rpm mould may not be the best way to go
  • further investigation of dpkg suite, including source
  • attempt completion of simple mocked-up bash script
  • problems with dependency checking - there doesn't seem to be a way of delegating this to the dpkg suite, so needs to be scripted

w/c 30.Nov

  • Decided that bash script wasn't sufficient (it didn't have appropriate data structures, nor did it have library routines to do the dependency checking). Trying perl...
  • investigated library routines available as part of DPKG::Parse, but these didn't seem comprehensive enough
  • took a look at updatepkgs on SunOS , but noted that routines did not include full dependency checks.
  • took another look at DPKG:Parse, and tried to use library routines to build data structures from Debian package information - but not overly successful.
  • investigated library routines available as part of libapt-pkg-perl (essentially perl wrappers to call libapt-pkg C routines), but need to learn more about object data structures in perl in order to fully understand use/implementation of DPKG::Parse & AptPkg .

w/c 07.Dec

  • still investigating use of libapt-pkg-perl (AptPkg ) library routines, and used to build & interrogate package data structures
  • took a look at the source for apt-get to see how dependencies were dealt with.

-- RogerBurroughes - 14 Dec 2009

Topic revision: r8 - 14 Dec 2009 - 13:54:03 - RogerBurroughes
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies