This is the mail archive of the
ecos-maintainers@sources.redhat.com
mailing list for the eCos project.
Re: ecos-opt
Andrew Lunn wrote:
As (ex-)Red Hat folks will remember, it was decided way way back to split
off the network stack and SNMP directories into a separate "ecos-opt"
hierarchy in the public CVS tree. And so it has remained to this day.
How does fit in, if it does, with the idea of going towards lots of
separate packages. This is something you eCosCentric guys keep
mentioning, but have not really said much in detail in out in the
open.
It's always been a goal. Although we've mentioned "2.1" for this, "2.1"
has been a placeholder for "a future version". We haven't really thought
much about what a real 2.1 should have - and in particular whether it will
have the separate packages.
Just so everyone knows what the goal of the packages is, the idea is that
users don't download a monolithic release, but instead a small set of
infrastructure host tools, in particular a greatly enhanced eCos
Administration Tool. When a user runs that, they then get the chance of
downloading packages from the master site (or mirrors), but can choose
which packages they want, so they only download what they need. So someone
needing only one target hasn't downloaded a zillion other HALs. They'll be
able to confirm they are happy with the licensing too.
The other advantage is we can finally take advantage of versioning, so
that you can have multiple versions in a repository at one time. You can
download different versions using the admin tool (perhaps a stable version
versus a beta version) and install them into your local repository.
One very good benefit is that it makes it much easier to make sweeping
changes to packages because you would then be able to specify in CDL that
a package "requires" not just a particular package, but a particular
package version. So, say we needed to make a backward-incompatible change
to the ARM HAL, perhaps an entire rewrite; we don't need to break every
target and fix it... instead we just bump up the major version number;
every HAL package that has a dependency on it would have specified the
version number it was written for (a major version bump would indicate a
version incompatible change of course) and put that in its CDL. Of course
we could still release new versions of a "version 2 series" ARM HAL, as
well as a "version 3" - development doesn't have to stop.
This has consequences of course, like ecos.db will be generated from
package information by the admin tool; and documentation must come from
each package... in fact this gets more fun when you consider you need the
appropriate documentation for the package _version_ as well.
Obviously with the proper infrastructure in place to do this, we make it
easier for third parties to seamlessly distribute their own packages.
Possibly even binary only packages. Although we won't distribute them from
our master site (probably), it's always been intended to permit this, and
is indeed one of the reasons for the GPL exception.
It seems to me these things are going in opposite directions. Hence i
think im missing some information....
It's an orthogonal issue. The CVS repo should be straightened out because
it needs to be. But even with a package based distribution we still need a
CVS repository... it's only officially released packages that would be
distributed that way; development would still happen in CVS as at present.
And just because someone made a change in CVS wouldn't (necessarily) mean
a new package is made available. Each package would get developed at its
own rate, and would have their own maintainer who decides that.
Hope this helps explain things a bit anyway!
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[ can rejoice because thorns have roses." -Lincoln ]-- Opinions==mine