On Tue, Dec 01, 2009 at 05:23:54AM +0100, Martin Bähr wrote:
> hmm, this is very! interesting, does that work with debian too?

A "dpkg" container hasn't been written, though I keep poking Ken
and suggesting it!  If you want to see how simple it can be to
write a capsule delegation layer, take a look at the file
conary/local/rpmcapsule.py -- it's about 12K, but it is not
that complex and is fairly significantly commented, which was
done specifically to make it easy to add new capsule types.

> this will allow me to introduce conary to places where people do expect
> a genuine rpm or deb based system.

Exactly!

> is there any rough howto for using this yet?

Nope.  We're in the process now of making formal releases of the
technology that supports this process -- conary, conary-policy, and
rmake in particular.

To use what we're doing here with RHEL will require a license from
Red Hat for RHEL as well as rBuilder.  But Boots won't require any
such license.

At the low-level technology end, the howto is simple.  It's a new
recipe type, CapsuleRecipe; and a new build action, addCapsule.
Here's a prototype for a capsule package that includes some python.

class somepackage(CapsuleRecipe):
    name = 'somepackage'
    version = '1.0'
    def setup(r):
        r.addCapsule('http://example.com/somepackage-%(version)s-1.i386.rpm',
                     use=Arch.i386 and not Arch.x86_64)
        r.addCapsule('http://example.com/somepackage-%(version)s-1.x86_64.rpm',
                     use=Arch.x86_64)

(We'll use factories and superclasses to do the same thing more
automatically; you'll seem them in Boots -- for most cases we'll
just check in a manifest file and some RPMs and the factory and
superclass between them will figure out the rest.)

Note that if you have python code in a package, you can (just as with
regular packages) add packages to the buildRequires that provide those
python dependencies, and Conary native python dependencies will be
calculated and attached to the package.

When conary 2.1.0 and friends are added to fl:2-devel (shortly...),
they will ignore "rpm:" dependencies so that you can package up
RPMs as capsules and install them on a foresight system and things
should just work.  On an rpm-based system, of course, you want
"rpm:" to be honored, and they will be honored in that case; which
dependency classes are honored is configurable.

Hope that helps.
_______________________________________________
Foresight-devel mailing list
Foresight-devel@lists.rpath.org
http://lists.rpath.org/mailman/listinfo/foresight-devel

Reply via email to