[lsb-discuss] LSB conference call agenda (Tuesday, September 5, 11am ET)

[Dan Kegel]

On 9/5/06, Dallman, John <jgd at ugs.com> wrote:
> >   - LSB SDK: What do ISVs want to see re workflow? Today, we
> >     provide a compiler wrapper and a chroot build environment. Both
> >     approaches seem overly heavyweight to me--if it were me,
> >     I wouldn't want to change either the compiler or the build environment.
>
> I'm an ISV working with this stuff. We find changing the compiler
> perfectly acceptable, although the chroot environment isn't.

I'm an ISV experimenting with this stuff, too.
I think both are needed.
In very large organizations, you might find a preference
for the chroot option, simply because it's more foolproof.
On a small team, everyone can know "Oh, I have to be careful
to not access anything not in the LSB", but when you have many teams,
you can't expect knowledge to diffuse well,
and a chroot helps enforce the rules a bit better.

 > >     Could we implement something that could be more seamlessly
> >     embedded in existing build processes, such as post-processors
> >     that check object code created by the compiler and that causes
> >     the build to fail if there are problems?
>
> That one sounds kind of hard. You need to be able to decode system
> calls, essentially completely: you're doing something equivalent to
> checking if an image would run on a system that had only the LSB
> facilities available.

It's doable.  If you try this, make sure it works with icc.  I have found
that the LDPRELOAD style of hook doesn't work with icc, but the
style used by zlibc does work with icc.

> >   - LSB SDK: What additional tools should we provide in the LSB SDK?
> >     A tool that makes it easy to build packages? A tool that makes
> >     it easy to bundle up external dependencies? A tool that makes
> >     it possible to target multiple LSB versions with a single package
> >     (e.g., so ISVs can support LSB 3.0 and RHEL 3 in one package)?

I would like the sdk to include a tool to translate the .lsb packages to .deb
packages.  We have to do this because we want to have a Debian/Ubuntu
repository, and apt-get currently doesn't support the .lsb format.
(We're looking at fixing that, but the lead time for such a change is long.)

> we'd like the compiler wrappers to be a bit smarter about the options
> they see and libraries they include, so that we can build IA-32
> and AMD64 LSB code on the same machine. Currently, one can install
> either the IA-32 or the AMD64 versions of the SDK on a machine,
> but not both, and it doesn't seem to be possible to build IA-32
> with the AMD64 LSBCC.

I agree it would be nice to support cross-building lsb packages.

BTW it's true that ISVs run into problems with compilers, and
you can't really force a particular compiler version on all ISVs.
- Dan