Re: [Ltib] some general questions about the structure of LTIB

[Stuart Hughes]

Hi Robert,

The GPP (Global Package Pool) is just an archive, you can determine
nothing by looking at it alone.  It contains all the public content ever
used by LTIB.  This allows any version to build as the references to
content are always valid.  The idea is that nothing silently goes away.

The spec files on the other hand do allow multi-versions, but this is
discouraged.  Sometimes though for various reasons a platform may need
to break this guideline.  The spec files which are named _pkg_.spec
represent the latest preferred common version.  So unless someone has a
really good version they should just pick up busybox.spec, which is
mapped in config/userspace/pkg_map.

Regards, Stuart

On Sun, 2008-12-21 at 10:29 -0500, Robert P. J. Day wrote:
>   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
> ========================================================================
> 
> 
> _______________________________________________
> LTIB home page: http://bitshrine.org
> 
> Ltib mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/ltib