ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] Multi-user LTIB


From: Stuart Hughes
Subject: Re: [Ltib] Multi-user LTIB
Date: Wed, 06 Feb 2008 14:48:45 +0000

Hi Ken,

It is intentional that /opt/{freescale,ltib} are common on a host
machine.  The reasons are:

* Ensuring that all content referenced in packages is the same
(/opt/{ltib,freescale}/pkgs

* Reducing overall installation size: if each instance
had /opt/{ltib,freescale}/pkgs, it would be a big overhead

* Sharing the common host support packages so that when something breaks
I can be sure what environment (host tools) this happened (for most
things).  The discipline this imposes is that backward compatibility has
to be ensured (which I try hard to do).


You seem to be worried about /opt/freescale/pkgs.  Let me try to explain
the purpose of this:

* /opt/freescale/pkgs, /opt/ltib/pkgs, (and very old /var/tmp/pkgs),
LTIB_INSTANCE/pkgs are local directories where ltib will look if it
can't find a file referenced in a <pkg>.spec file in rpm/SOURCES.  If it
can't find the file there, then it looks in the package pools which are
on the network somewhere. These are listed in .ltibrc, if you look at
the HEAD of CVS from savannah you'll see:

%pps
ppp
gpp

# The URL of the PPP (Private Package Pool) private code repository
%ppp_url

# The URL of the GPP (Global Package Pool) master code repository
%gpp_url
http://bitshrine.org/gpp/

You can see we have two, the PPP (Private Package Pool) and the GPP
(Global Package Pool).  In the case of savannah CVS, the actual url for
the ppp (%ppp_url) is left blank.  Inside Freescale we have an entry
that refers to a server where our un-published work is held.  Most of
this content is migrated to the GPP (global) after testing/review.

The reason I've left in the "ppp" in the list of package pools is so end
users (such as yourself) can setup your own PPP.  All you need to do is
to have a webserver which you can "wget" files from.  These have all
their files located in a single directory.

The intention of this setup and a fundamental of LTIB is that one a file
is in a package pool, then it never gets modified.  So this means that
file xxyyzz will always be the same (immutable). So ideally a filename
can be guaranteed to always be the same thing.  To make sure this is the
case, every file on the PPP/GPP has a corresponding md5sum file.  

The normal work flow I'd expect would be:

* Work on a new package locally.  Possibly with more than one user on a
machine, sharing /opt/freescale/pkgs etc.

* Never overwrite existing files in /opt/freescale/pkgs.  If it turns
out the 2 people named a patch the same, then they'd need to consolidate
on a single patch, or re-name one of them (-1 suffix, or something
meaningful).

* Once a user has built their package *and* they want to share this with
others in the group (possibly on a different host machine):

  * Upload their files to their groups PPP server. 
  * CVS commit (or whatever your SCM, the spec files 
    referencing this content)

* If that work is suitable to be published to the world (e.g. it has a
suitable license (GPL etc) and you want anyone to be able to get at it.
You can upload it to the GPP: http://www.bitshrine.org/#ref_15 .  

I've attached a diagram that shows how this works.  If you replaced
"Freescale" as the PPP for your own company you can probably visualise
how this can work for you.

Notes:

1/ The GPP/PPP upload script could be made available if you want to
setup you own PPP.  The usefulness of this is that it records meta-data
about the files being uploaded.

2/ To figure out which files have not been uploaded to a PPP/GPP you can
run: ./ltib --dltest

3/ You can have as many package pools as you want.  If the content is
not found locally (lpp, or ldirs) the the package pools are searched in
the order listed in the %pps in the .ltibrc file

4/ When content is uploaded to a package pool and you update a spec
file, the next time it builds that package it will download the md5sum
file and verify this against any existing local file.  If there is a
mismatch you will be alerted and be able to fixup the situation (the
offending file is renamed to filename.bad).

Hope this helps a bit.

Regards, Stuart


On Tue, 2008-02-05 at 14:31 -0500, Ken Gilmer wrote: 
> Hello :)
> 
>    We use LTIB extensively and it is working well for us.  Once pain  
> point we have is that we have one build machine that is rather  
> expensive/fast that multiple users are building on.  AFAIK LTIB  
> stores some state in machine-global locations (such as /opt/ 
> freescale).  While we haven't been burned yet I'd sleep easier at  
> night if all state for ltib was kept inside it's install directory,  
> insuring that two different users didn't clobber each other.  I've  
> played around with variables in the script but my modifications cause  
> LTIB to break.  Is there a recommended approach or strategy to safely  
> keeping LTIB instances isolated on a given machine?
> 
> thanks
> ken

Attachment: ppp_gpp.png
Description: PNG image


reply via email to

[Prev in Thread] Current Thread [Next in Thread]