Re: Crush 2.0 abandoned -- Review and Feedback from Neil's Post of August 7th
There seems to be a lot of work, and it's a very steep learning curve.
One has to be very Debian savvy before the extra knowledge and time
required to be an emDebian developer/maintainer.
I there anyway to partition this so that a smaller knowledge/experience
base is required to contribute ??
I notice uClibc is a candidate, but I remember a post about embedded
glibc which was/is a smaller lighter libc based on glibc sources. Would
this be a better candidate than uClibc ?? Should glibc, embedded-glibc
and uclibc all be "supported" ??
Cheers, Brendan.
Prince Riley wrote:
> I'm going to ask the members of this list who haven't as yet spoken up
> about the items on Neil's post to please do so by Friday. Once we
> have those idea, suggestions, and recommendations we can put those
> ideas into a draft summary.
>
>
> On Wed, Aug 5, 2009 at 3:53 PM, Neil Williams <codehelp@debian.org
> <mailto:codehelp@debian.org>> wrote:
>
> On Wed, 5 Aug 2009 14:52:22 +0000
> Prince Riley <wmarketing3@gmail.com
> <mailto:wmarketing3@gmail.com>> wrote:
>
> > Neil,
> >
> > We are all very glad and appreciative of the great work you've done
> > so far. We all understand and respect your decision and wish you the
> > best as you try to recover your health.
> >
> > My question, and one I'm sure has also occurred to others interested
> > in this project, is how do we move ahead during your absence.
> Perhaps
> > you can offer some advice or recommendations on how members of this
> > list can help you transition your efforts so we can maintain the
> > project's momentum and achieve its goals.
>
> It isn't about helping me transition anything, someone else needs to
> take over maintenance and development. This is the "bus" scenario -
> whereby a project has had only a single active developer and once that
> developer is lost, it's about going back to first principles and
> picking up the threads. I can help in small areas but my time is too
> limited to go through the details, just the overview.
>
> Seeing as you asked, maybe this little list will give you some idea of
> why I had to abandon this particular task - I'm not convinced that the
> problems can be fixed before Squeeze, even if someone else takes
> on the
> role. Several stages rely on other tasks within Debian that may or may
> not make it into Squeeze. The list is by no means complete either!
> Even
> before my illness, I had *serious* doubts about whether Crush 2.0 was
> possible.
>
> 0. You'll find plenty of hacks, errors and mistakes that have remained
> in the current scritps from the earlier development phases. It is
> worth
> revisiting things like that and seeing what breaks without them.
> Ensure
> you test with more than a few packages - there are various gotchas
> that
> only apply to a handful of packages and some of those packages have
> since had new upstream releases that may well have fixed the issues
> that led to the hacks in the emdebian-tools scripts. Other
> improvements
> elsewhere could also lead to some procedures within the current
> scripts
> becoming redundant or new ones needing to be devised.
>
> 1. Read the EmdebianCodeAudit wiki page and supporting pages, go
> through and cross-build each package to work out what each audit point
> means. Results are for armel, using emsource and emdebuild. Replicate
> results using chroots builds (with empdebuild) wherever possible.
> Various other parts of the wiki also need to be cleaned up, as
> does the
> website itself which still has a fair bit of outdated information.
>
> 2. Continue discussion on how xcontrol support can actually be
> implemented. Check how it is used in the CodeAudit and tie that into
> the developments at DebConf9.
>
> 3. Learn the emdebian-tools scripts and manpages, read the source code
> and get a handle on how things currently work - taking over
> maintenance of a native package means taking over the source code too,
> in effect the "upstream".
>
> 4. Struggle with the inherent weaknesses in apt-cross which lie in the
> horrible apt perl bindings - the most recent version of apt has (once
> again) broken these bindings and apt-cross needs a patch to continue
> operating. (Something to do with /etc/apt/preferences.d/). Hope that
> someone gets apt to understand multiarch so that this whole issue can
> be removed - you need a C++ expert for that role.
>
> 5. Get the toolchains back into installable state - I can't upgrade my
> own armel boxes today but I don't have time to investigate why. Build
> scripts that ensure that this persistent problem is fixed for the long
> term and across all supported architectures.
>
> 6. Create a local mirror and use the scripts in emdebian-qa and
> emdebian-tools to upload cross-built packages into the repo and start
> building a small set of packages for armel. Don't proceed to other
> architectures or make the mirror publicly accessible until the rest of
> the issues in the Code Audit have been fixed.
>
> 7. Pick up development of emdebian-tools from existing SVN - there are
> some changes in SVN that still need testing.
>
> 8. Start developing ways to test and fix an existing problem in that
> the ./configure scripts in some packages insist on looking for stuff
> in /usr/lib/ and then linking against the shared libraries
> in /usr/arm-linux-gnueabi/lib/ etc. This is a disaster waiting to
> happen and must be fixed before Crush can progress to more than one
> architecture. In the same manner, check builds for /usr/include/
> pollution and drop the apt-get build-deps stage in a clean chroot. If
> no xcontrol file, allow (nay require) native deps.
>
> 9. Make notes in CodeAudit of packages that fail to rebuild twice in a
> row and detail why.
>
> 10. test and document the proper support for CC_BUILD in autotools.
>
> 11. Get Build-Depends split into debian/control and normal Debian?
> Possibly as well as Depends-Install (installed on build) and
> Depends-Runtime ? Building a *static* chroot for another machine, only
> needs runtime stuff. Allows native cross-versions of packages, smaller
> installed images. No way to put a prefix in front of maintainer
> scripts
> for config files. Need a mangling frontend in dpkg before calling the
> script. Install time scripts vs runtime scripts. (A topic briefly
> discussed with Wookey, hopefully my notes aren't too brief for the
> idea
> to be reconstructed. I knew what I meant at the time.)
>
> 12. Create a new wiki page to detail things like this and whatever
> else
> comes up as you go. Link it from the EmdebianTracker page?
>
> 13. Please don't come to me continually for input, if Crush is to
> continue, someone needs to take over maintenance and that means filing
> and fixing the bug reports without looking at me to do it. (You'd
> alter
> the Maintainer: field in debian/control to remove my name and enter
> your own so that the bug messages for the emdebian-tools source
> package go to you or to this list.)
>
> 14. Work out how to fix "X-Build-Cross-Libtool: yes" which is probably
> tied into other libtool issues identified in the CodeAudit to do with
> refreshing the autoconf and libtool metadata prior to attempting the
> cross-build.
>
> 15. Get CMake build systems cross-building properly.
>
> 16. Get a mini-perl and some kind of python support.
>
> 17. Solve what ever other issues turn up during these processes.
>
> 18. Fix all the packages that used to cross-build for Crush 1.0
> but not
> longer cross-build in unstable. (The CodeAudit identifies these
> packages, one is gcc-4.4). Work out and gain consensus on whether such
> packages should *not* be cross-built from source and just "borrowed"
> directly from Grip. This is a Policy decision about whether Crush
> should be 100% buildable from source or whether compromises are
> acceptable. Mixing Crush and Grip will *only* work if the xcontrol
> support is fixed such that changed functionality is always encoded
> within the binary package name like libgconf-noldap-2-4 etc.
>
> 19. Identify *new* packages that have become dependencies of necessary
> packages in Crush since the release of 1.0 and then work out how
> to get
> each of these to cross-build.
>
> 20. Test these packages with real systems and see if the rootfs
> scripts
> can still operate and what new bugs arise at installation/deployment
> time.
>
> 21. Manage the repository to cope with britney (the script that
> migrates packages from unstable into testing in Debian).
>
> 22. Manage the repository to cope with testing-proposed-updates once
> the Squeeze release freeze starts to happen.
>
> 23. Test and report bugs with the locale support via Emdebian
> TDebs and
> langupdate.
>
> 24. Fix issues like the bulky gconv files in libc6 and test with the
> tzdata support.
>
> 25. uClibc support
>
> 26. Finalise the cache value support in dpkg-cross and add to it if
> necessary. Consider deploying the cache values into the Debian package
> such that the files can be created at build time on a
> per-package-per-architecture basis.
>
> 27. Keep an eye on multiarch developments and feed into the process to
> ensure Debian gets a usable cross-build environment based on
> multiarch.
> Get dpkg-cross merged into dpkg as soon as multiarch is supportable.
>
> 28. Whatever else I've forgotten.
>
> Is that enough for now?
>
> --
>
>
> Neil Williams
> =============
> http://www.data-freedom.org/
> http://www.linux.codehelp.co.uk/
> http://e-mail.is-not-s.ms/
>
>
Reply to: