Re: cleaning up lsbfuncs.sh

It looks like we started on this since its in with vsxgen.

Basically this should be a vsxgen only library

We need to ensure the version in with vsxgen has all
the functions we need and then to remove the others.
So some integration is needed, since li18nux seems to unset LC_ALL
in one piece, usergroups adds its own build target

At the moment the subset versions will overlay/overwrite the 
vsxgen version when we do a source build

I also need someone who has login rights on the cvs machine to
remove lsbinstall from within the lsb-runtime-test directory,
and tidy up the wip directory.

We'll want to tag the tree for 3.0 before we do this restructure
as it will likely destabilize things

Yes, i think we ended up not using lsb_setarch() (if that is
so it could be removed).
regards
Andrew

On Jun 25,  4:40pm in "[Lsb-test] cleaning ", Wichmann, Mats D wrote:
> 
> I wanted to add some generic stuff to lsbfuncs.sh -
> there isn't a function that supports the precise
> thing that happens for install_initd and remove_initd
> but it's close enough that making another convenience
> function seemed sensible.
> 
> Certainly the first choice is to modify the copy
> in place (wip/initd/SRC/common/lsblib) but as
> I was looking for where that file was kept I notice
> we now have six of them in the tree - 
> harness/vsxgen, modules/li18nux, modules/lsb-fhs,
> modules/lsbinstall, wip/lsbinstall, and wip/initd.
> And they're not all the same!  The last three started
> life as copies of the modules/lsb-fhs one, so
> excepting cvs auto-added comments ($Log$), they're
> the same; not the same as the first two which are
> identical to each other. Sigh, that's confusing:
> 
> Six files, two revisions
> : two copies of one revision
> : found copies of another revision, indentical except
> for generated comments
> 
> This just on principle seems like a Bad Thing (tm).
> 
> Note: there are also six copies of shfuncs.sh, but
> at least those aren't showing any variation (except
> for the same comment thing).
> 
> It seems odd to have six copies in the cvs tree,
> when the test suites are built by merging with a
> tet_vsxgen tarball anyway (did we finally get to
> where that's coming out of the cvs tree? or are
> all six copies of these files effectively ignored?)
> 
> Also, I notice lsb_setarch in lsbfuncs.sh has never
> been updated since the LSB was x86-only, as it returns
> answers for i486 and sparc (!) else "unknown".  I
> guess that function isn't used much :-)
> 
> 
> 
> 
> 
> Any thoughts on how to make this a little cleaner?
> 
> 
> _______________________________________________
> lsb-test mailing list
> [email protected]
> http://mail.freestandards.org/mailman/listinfo/lsb-test
>-- End of excerpt from Wichmann, Mats D