Re: developers' kit
On Fri, Aug 10, 2001 at 02:31:26PM +0000, M. Drew Streib wrote:
> When talking to developers now, and reaching beyond those that might
> work directly on the spec/tests/impl and are simply interested in
> making lsb packages of their work, I find it difficult to hand them something
> that they can make use of. I realize that it is still very early for
> this type of participation, but I think you'll find a lot more
> developers willing to work with alpha/beta quality development tools
> than you might think.
> It might also just be helpful to get developers in the mindset of building
> lsb apps, and familiar with the process. We'll end up with more beta
> testers for the test suites as well.
> I envision some sort of "developer's kit", which would contain an
> rpm/deb and a short instruction manual.
> Instructions might include:
> * Installing the rpm/deb on their system
> * export CC='cc-lsb'
This is ok if configure scripts, makefiles etc. reflect this.
The impl/xdevel prototype patches gcc to do the right thing.
We hope that much source packages just build right then.
> * Make the application. (I'm guessing that cc-lsb will default to
> headers in /usr/include/lsb or equivalent.)
We could hack such a cc-lsb wrapper script. But again: Hand editing
makefiles and config stuff could be needed. So when building
for lsb, only the "official" lsb includes may be visible.
> * Use lsbappchk on the finished binary(ies)
> * -In the beta stages- Please report any unexpected behavior from
> lsbappchk
> * Package using rpm. (Should we provide an rpm-lsb which is the right
> version of rpm?)
You can not easy have two database-incompatible versions of
rpm on your machine. There is also a library librpm were we
must make shure that we do not interfere with the "other rpm".
If we only want to build packages without changing the rpm
database, we had to patch this rpb-lsb version so that it can not
use the database: ie. can only install source rpms, build source
rpms and build binary rpms.
This idea needs discussion. It would stop rpm version wars.
But: We had to maintain it.
> * Offer their lsb app up for review
> I think that the overall process isn't _that_ hard, but those not
> totally familiar with the pieces of lsb may find difficulty unless this
> is documented well. Also, I'm pretty sure we don't have that rpm/deb
> I'm speaking of.
>
> Andrew, I know you're working on an OS check binary RPM, but it sounded
> in this morning's call like that a sample implementation/developer's
> type rpm wasn't yet in the works. Is that correct?
This time there are "tar balls" and a CVS repository. Work is not completed.
> I'd be able to work on the documentation side of this, but don't
> feel comfortable being any authority on building apps for lsb.
You could try to identify the open questions and check in bugs
against the sample implementation.
> 1) Does this type of kit seem appropriate eventually?
> 2) Could we build such a thing soon, or is it too early? (I think that
> this is a pretty important step to getting feedback on a lot of things,
> so I'm voting for earlier rather than later with this.)
> 3) If we built an alpha version of this soon, would it be at all useful,
> or would it be so alpha that a final version would differ greatly?
> (Even if the process is right, that will offer a significant help
> in educating people to building lsb apps.)
> 4) Is my general bullet outline of the process even close to correct?
modulo my remarks, I think yes.
--
______ ___
/ ___/__/ / Caldera (Deutschland) GmbH
/ /_/ _ / /__ Naegelsbachstr. 49c, 91052 Erlangen, Germany
/_____/_/ /____/ http://www.caldera.de
==== /____/ ===== Dipl. Inf. Johannes Poehlmann, mail: jhp@caldera.de
Caldera OpenLinux phone: ++49 9131 7192 335, fax: ++49 9131 7192 399
Reply to: