On 09/11/06 00:49:26, Jim Heck - Sun Microsystems wrote:
In effect, I expect that Emdebian will be upstream of many embedded development projects (hopefully many of which will be able to contribute back to the main effort over time).
OK.
Such a project would have a team of some size that is responsible for developing the product, providing updates and fixes over a product lifecycle, etc.
A separate team like that is essential for the kind of process you describe. I think we both agree that this is not a job for Emdebian.
OS, while performing some other main function. In my opinion, this is one of the things that makes Linux great, it's ability to be harnessed to create new and interesting products that might not otherwise have existed.
Absolutely.
No I don't expect a stable distribution. I agree that this is not the job of the Emdebian developers. The fixed distribution I speak of is created downstream by the product development teams taking Emdebian into their own environments. They are ultimately responsible for putting together a system that works for their application.
I'm glad of that! :-)
Understood, but I'll just point out that what you are describing is an end user model where the end user directly uses the operating system (and maintains it). In the case of many embedded development efforts, this task is performed by a development team and not the end user.
OK.
I'll agree with you wholeheartedly. Your analogy is good too. Unfortunately, this is how embedded development teams working on embedded products are forced to work. Once again, however, it is not a problem for Emdebian. I don't expect that to ever be a 'baked' distribution.
OK.
This stripping out is exactly what makes Emdebian very attractive to embedded development teams considering Linux as an OS. There are companies who provide Linux distributions that have already done this, but as you said, these baked distributions cause their own problems. They take embedded developers further away from the upstream sources, and cause long lags in the availability of patches and fixes coming from those sources. This is why I think the Emdebian effort is interesting an will be popular as a basis for embedded development.
I understand your perspective now.I'm still not convinced of the need for this insistence on not changing toolchains as soon as the next set is available. In a Debian system, the transition is handled for you, there really is *less* impact from moving *with* the transition - and thereby the support - compared to staying put and trying to force a "derivative" project against the flow of the upstream project.
Good points all. Yes this is of course the way it has to be for Emdebian. I'm just pointing out that it is the complete opposite for downstream embedded development teams, but that is once again their problem to solve.
I think that this may be unnecessary and even counter-productive. It is your problem to solve - if you decide to go against the flow - but, personally, I think you are underestimating the benefits of going *with* the toolchain updates that are scrutinised *so carefully* by Debian upstream.
Historically, it is believed that in productdevelopment/testing more time is incurred by changing toolchains than the occasional problem of having new software that won't work properly with older compilers. Teams do change tools over time, but not on a constant basis.
Trying to tie a rolling update system like Debian/Emdebian to a static toolchain - no matter how long a delay is involved - pushes the packages towards the problems of a baked distribution.
Debian is radically different from other GNU/Linux distributions - I think it is a mistake to desire the benefits of the Debian approach and yet work against the methods by which these benefits are generated.
The closer emdebian gets to full Debian acceptance, the easier it will be for other projects to benefit from the toolchain management that Debian does so well.
Once again I'm not advocating this for Emdebian, but describing what would happen downstream in a development group. By and large I agree that it would probably be better to update as much stuff as possible on an occasional basis and have a consistent snapshot of Emdebian.
Even a snapshot is a bake of some kind. Not running a system-wide update/upgrade disrupts the mechanism that delivers the very benefits that you desire.
This is probably what is best to strive for. Unfortunately what happens in a product development group is that one has to weigh the QA risks of changing more than you need to change to get one part of a system past a nasty bug.
This is familiar from Debian: it is the principle behind non-maintainer uploads to fix release critical bugs in packages. Touch as little as possible, let the maintainer deal with other issues.
Overall things usually get refreshedevery so often on a wide scale. The problem comes when there is a critical bug that needs some new version of a single package.
Debian also has to do this from time to time, by backporting a change to 'stable' - it is not easy.
I still think your model of not changing toolchains is an invitation for a lot of unnecessary work.
What I'm talking about here is that when building on a host in a crossed environment for a target embedded system, two Debian environments are involved, and the process is either seperable or it isn't. If it is not seperable, then there are dependencies of the installed libraries/packages on the host system that link it to the final target system.
OK. Yes, Emdebian is separable from Debian in these terms. Emdebian can be updated without Debian - *if* the developer has a machine with sufficient power. Most emdebian systems will not have sufficient resources.
Emdebian is a spectrum - it covers everything from devices smaller than an iPAQ to devices that are quite capable of running a full Debian installation themselves. At LinuxWorld Expo, there was a demo ARM system running a full Debian install - using the existing ARM port of Debian. A machine that is capable of installing a full Debian installation will also be capable of installing the full range of emdebian packages - including building/installing a native gcc. Once that is possible, you have an emdebian system that can build emdebian packages just like it can build debian ones.
However, this separation only works when the emdebian packages *continue* to be updated with packages built with updated toolchains. Otherwise, returning to the Debian package stream will be a difficult and painful experience.
In a non-seperable system you will only everbe able to build new software for the target using the same host (the two are linked by "weird" dependencies).
By 'same host' do you mean the same physical machine or a similar machine running the same host environment / operating system?
If 'same host' means, as you infer below, a Debian machine, then there is very little separation in reality - emdebian is just a smaller debian so, naturally, the two can build packages for each other.
If the system is seperable,then you could come along with a different host (still Debian), move some set of stuff over to the new host, and continue to update and build software for the target system.
Yes, that will have to be possible - building emdebian packages cannot be restricted to the small set of emdebian developers on this list who have some weird set of emdebian tools. The tools we will use will be installable on any Debian system and *must* operate interchangeably on all Debian architectures and installations.
The set of things you would move from one host to the second host are the state that really belongs to the target. At minimum this is the set of source packages being built for the target. The question I was asking, really, is whether there were any host dependencies beyond that set of source packages.
No. Once built, an emdebian package can be installed on any emdebian device with sufficient resources. Building emdebian packages will be identical on all Debian installations. To install a package, the *only* thing that needs to be copied from the cross-building host machine to the emdebian target machine is the binary .emdeb archive. Dependencies would be transferred in the same way.
The installer is a different issue.
I'll check out OpenEmbedded. I see your point about Emdebian having its roots in stripping down the existing OS and not about trying to be a new OS, but I don't think that's all it will ever be used for. What is Debian if not full featured Linux with great package and package dependency handling. That is precicely what is needed as the basis for many embedded development projects.
True - but a lot of what you want from emdebian is a side-effect of the emdebian process. As such, it is hard to forecast how such side effects will change over time, especially if you insist on having a toolchain that is older than the current Debian/Emdebian default.
IMHO, everything will be a lot easier for everyone if projects built from a Debian/Emdebian upstream continue to use the Debian/Emdebian systems and that includes a rolling upgrade that includes enormous amounts of time and effort in handling all manner of toolchain transitions across the entire spectrum of Debian packages. THIS is how Debian creates the benefits that others find so attractive - I find it hard to believe that people think that the benefits can be transferred to other proects without using (or continuing to use) the underlying mechanism.
-- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpXAGyVxcezN.pgp
Description: PGP signature