[lsb-discuss] Using rPath for the LSB SI

Theodore Tso tytso at MIT.EDU
Sun Feb 10 17:01:29 PST 2008

On Fri, Feb 08, 2008 at 04:45:48PM +0000, sbin at reboot.sh wrote:
> Hi again,
> i've looked a bit at the current stuff in bzr, lsb mailing list archives, 
> and so on. Also, parked a place in #lsbsi and #lsb (w/ doniphon as nick).


> Regarding timelines, it seems achievable to have a base implementation 
> (3.2) on x86{_64} arches  in a two weeks time frame. Before i start doing 
> it, i'd like to chat a bit more with those more involved in the current 
> setup (namely - i think - licquia) in order to learn/grab from their 
> experience (in order for me not to be impolite (as i've not seen any 
> reference to conary/rMake in thew wiki/MLs) please bridge/introduce me with 
> licquia.

There are weekly conference calls on Wednesday at 11am US/Eastern, and
I have brought it up there.  So folks are aware of the idea to use
rPath for the LSB SI, although they haven't been introduced to you.
So hopefully you won't mind if I do so now, with this e-mail message.  :-)

Antonio, please meet the LSB workgroup!  We're really glad to have

Actually, Sam Hart is actually the developer who is spending the most
time on the Sample Implementation these days, so if you would like to
chat with him a bit via e-mail and/or IRC, I would strongly encourage
it.  He's actually quite enthusiastic about trying out rPath, and has
apparently started a test project on the rPath community web site to
play with the tools.

One of the things which perhaps you could discuss with Sam is what to
do about the LSB 3.2 Sample Implementation.  I had been assuming that
we shouldn't count on being able to port to all of the LSB
architectures very quickly, and so that perhaps we would need to base
at least the initial LSB 3.2 SI on the old LFS framework, not switch
to using rPath to develop the LSB SI until the 4.0 release at the end
of the year.

Since we released the LSB 3.2 last week, we really should try to get a
Sample Implementation released soon (i.e., in the next 4 weeks or so),
and I had been assuming that it would take longer than that to get the
RPL2-based packages required for the LSB bootstrapped on all of the
LSB architectures: x86, x86_64, ia64, ppc32, ppc64, s390, s390x.

So my assumption going in was that we would work on the LFS and the
rPath based SI work in parallel, with the assumption that the rPath SI
would be primarily targetted at LSB 4.0, but it might be plan B
failsafe if it turns out that that LFS approach runs into problems
when we start adding the new packages supported by LSB 3.2.  On the
other hand, Sam is quite interested in working on the rPath tools as
well, and perhaps we should place all of our money on the rPath
approach for the LSB 3.2 SI.

My natural caution about whether we will run into bootstrap problems
on the non-x86/x86_64 architectures made me assume that we wouldn't
try to change the Sample Implementation engineering tools for the LSB
3.2 SI.  However, I'm willing to hear arguments if you and Sam are
confident that it would be faster/less risky to use the rPath tools
for the LSB 3.2 SI than to continue using the LFS framework.  Maybe
you could confer with him and others on the lsb-discuss list which are
interested in the sample implementation, and give a recommendation?

> Also, the new model offers/allows a whole new level of 
> doing/running testing/test suites. I'd like to talk about the potential 
> different ways of doing that too. Also, due to the whole nature of it, 
> conary repos _can_ work both (on this context) also as an SCM, what would 
> be something to talk and explore. (do note that fetching bzr stuff from pkg 
> recipes is trivial, it would be only a matter of simplicity).

Yep, Ken demonstrated that to me.  Let's see what other developers are
more comfortable with.  It might be that storing the patches in Conary
might make it easier to support future multiple versions of the LSB SI
--- in the long-run, it would be useful if we can easily inherit
bugfixes from RPL2 and then re-issue new chroot tarballs for LSB SI
4.0, 4.1, 4.2, etc. as necessary.  Note that some ISV's might want to
use a LSB 3.2 SI, even if after we release LSB 4.0 and the LSB 4.0 SI
is available, since if they can make their product work in the LSB 3.2
SI and certify against LSB 3.2, their product will work on more
distributions than if they use LSB 4.0.   

So picking a model which allows us to support a multiple versions of
the LSB SI with minimal effort would be a really good thing.  Today,
we don't really do this because of the engineering overhead involved.
But if we can find a way to easily support multiple LSB SI's,
including security bug fixes (which even in a Sample Implementation
might be nice to have if the ISV starts getting paranoid about running
the SI as part of their build/test farms), that would be a definite
nice to have.

						- Ted

More information about the lsb-discuss mailing list