From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16393 invoked by alias); 22 May 2003 10:43:00 -0000 Mailing-List: contact ecos-maintainers-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: ecos-maintainers-owner@sources.redhat.com Received: (qmail 16337 invoked from network); 22 May 2003 10:42:58 -0000 Message-ID: <3ECCA9AC.3020402@eCosCentric.com> Date: Thu, 22 May 2003 10:43:00 -0000 From: Jonathan Larmour User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.3) Gecko/20030314 X-Accept-Language: en-gb, en, en-us MIME-Version: 1.0 To: Andrew Lunn Cc: eCos Maintainers Subject: Re: ecos-opt References: <3ECBD40B.1080501@eCosCentric.com> <20030522073145.GS475@biferten.ma.tech.ascom.ch> In-Reply-To: <20030522073145.GS475@biferten.ma.tech.ascom.ch> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00043.txt.bz2 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