[suggest] Click, Kroc, ACE and a few other suggestions

Jonathan Day imipak at yahoo.com
Fri Jul 1 06:38:24 CEST 2005


Apologies for not reading through the details on
suggestions and package maintenance closely enough.
Anyways, onto the really important stuff - software.

I would like to suggest the following:


This is a modular software router from MIT, actively
under development, essentually a BSD license.

The homepage is:


There's only one package this would generate, at this
time, which is: click

It is not clear enough, at this time, whether it is
safe to split off the elements built into Click, as
opposed to being independent Click packages. They
would probably need re-baking as independent packages,
as the normal compile links them directly in.

Other than the usual stuff configure needs, it really
only depends on libpcap being present.

I'm maintaining the Click .spec file anyway, so
keeping rpmforge updated on it would be absolutely no
additional effort.


This is an implementation of the Occam 2.1/3
programming language, maintained by the University of
Kent in the UK, that is known to work on Linux ix86
and has been reported working on the *BSDs. It is
GPLed. Occam is mostly used for teaching purposes, but
I've been keeping the Freshmeat record updated and
notice that it seems respectably popular in general.

The sourcefiles are always placed in the maintainer's
homepage prior to the "official" homepage, and
pre-releases only appear on the maintainer's homepage.


Again, there would only be one package: kroc

This time, it would be completely pointless splitting
it up, as all the components are necessary and all are
updated together, even though the build script allows
for independent compilation.

It uses Gnu automake/autoconf, but has a wrapper to
use it. The build script does support updating by
means of wget, which is great for people compiling
from the standard tarball, but probably isn't as much
use when compiling from the .spec file.


ACE, the generic label, refers to three programs:

ACE itself, which is a framework of re-usable
components and patterns for high-performance real-time
distributed software of any kind.

TAO, which is a CORBA 3 ORB, using the ACE components.

CIAO, which is a CORBA Component Model, built on top
of TAO.

The three are otherwise independent, so you'd end up
with three packages:


There are two versions - a "stable" version that
rarely gets updated but is good for
industrial-strength CORBA work, and a more "dynamic"
version from the DOC group. Personally, AFAICT, the
DOC group version would be of far more interest to
most Open Source developers, but to keep things
distinct, I've proposed adding the doc- prefix.

The homepage of the DOC group version is:


The ACE system looks to be under the revised BSD
license, everything else in there is just a disclaimer
that they're not at fault if other people blow up the
world or get beat up by the RIAA. (Only they use
slightly more tactful language.)

There is another component, CoSMIC, which supports
Quality of Service for CORBA, but it is currently not
Open Source (they say soon) and it has other
dependencies I've not even looked at yet. It is also
not clear if CoSMIC will be part of the main ACE
bundle or distributed seperately, at this point.

I'm also tracking a bunch of packages related to the
sciences, foremost of these would be the Heirarchical
Data Format library, PETSc and SUNDIALS. They are
interesting, and in terms of scientific software are
reasonably widely-used. I am not cetain, though, how
wide a sweep of software RPMForge is going to attempt
to capture, though, so these are rather more tentative

For additional software development stuff, I would
also suggest OpenMPI, as it looks as though it'll blow
all other MPI software out the water. When it finally
gets out the door! It's intended as a replacement for
most of the existing MPI implementations, including
LAM, so I think there will be quite a bit of interest
in it.

Most good games are already in RPM format - and most
of those are in one of the RPMForge repositories
already. The only game that is massively
under-represented is Flightgear, which is GPLed but
RPMFind reports it as only in SuSE and Mandrake, both
versions out-of-date by quite a bit.

For all proposals above, I have SPEC files prepared
and would be willing to maintain them. In the case of
Click, as noted, I already do this anyway.

Any of these sound interesting?

Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 

More information about the users mailing list