[Ltib] some general questions about the structure of LTIB

[Robert P. J. Day]

  i think i know the answers, but i'm going to ask anyway just to make
sure i'm not labouring under any fundamental misconceptions about how
LTIB is structured and how i should be working with it.

  first, as i read it, the general package pool (GPP, at
bitshrine.org/gpp) should contain pretty much only:

  * supported tarballs (either .gz or .bz2)
  * patch files
  * MD5 files

and that's about it.  there can be more than one version of the same
package there.

  on the other hand, the spec files for those packages can be found in
the "ltib" package itself, which i've downloaded via CVS, and i'm
perusing the contents of dist/lfs-5.1 right now so, for example, i can
see the contents of zlib/:

  zlib.spec

which is for the 1.2.3 version of zlib.  and here's where i want a wee
bit of clarification.

  it's quite possible for ltib to support more than one version of the
same package, but there should be some correspondence between the spec
files and the packages that exist at the GPP, no?

  for example, let's pick on busybox.  in the busybox/ directory,
there are a number of spec files:

  * busybox-1.00.spec
  * busybox-1.1.3.spec
  * busybox-1.6.1.spec
  * busybox.spec

  if i select simply "busybox" as part of my ltib build, can i assume
that what will be selected will be the generic (unversioned) spec file
for that package (in the case of busybox, this would be for 1.11.3)?
which means that, if i want to select some other version, i can use
the "pkg_map" file for my build to override that?  so far, so good?

  sticking with busybox and supporting various versions, this leads me
to ask what busybox-1.01.tar.bz2 is doing in the GPP since there is no
spec file for it in the ltib CVS.  obviously, additional packages in
the GPP that are unreferenced by any ltib spec file won't hurt
anything, but is there any value to them?  i'm just curious.

  the same question can be asked of zlib, actually.  there is only one
zlib.spec file, for version 1.2.3, for which there is a corresponding
zlib-1.2.3.tar.bz2 in the GPP.  however, there is also a
zlib-1.1.4.tar.bz2 in the GPP.  any purpose for that?  if ltib still
wants to offer support for an older version of zlib, would it not make
sense to hang on to the older spec file as well?  i'm just curious.

  which brings me to my final question regarding upgrading a package.
if one wants to package a newer version of some package, it seems
possible to just add that to the GPP and to ltib without *forcing*
anyone to start using it, right?  for instance, my recent submission
of a spec file for i2c-tools-3.0.2.

  currently, ltib supports i2c-tools, whose spec file lists this as
version 2.8.1.  if i want to use the newer version and whip up and
test a new package/spec file and submit it for inclusion, i obviously
don't want to *force* anyone to suddenly upgrade.  but if it's
included with a spec file of i2c-tools-3.0.2.spec, would that mean
that no one would pick it up unless someone explicitly asked for that
version, given that they would still get the (default) spec file of
2.8.1?  until, of course, such time as that newer package has
established itself as suitably reliable that it could become the new
default.

  is all of the above reasonably accurate?  i ask since there are a
few newer packages i'm willing to upgrade/package and submit to ltib
for inclusion in the GPP, as long as none of that affects anyone who
doesn't want to be affected.

  thoughts?

rday
--

========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry:
    Have classroom, will lecture.

http://crashcourse.ca                          Waterloo, Ontario, CANADA
========================================================================