[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Ltib] LFS version
From: |
Jürgen Lambrecht |
Subject: |
Re: [Ltib] LFS version |
Date: |
Fri, 4 Mar 2011 09:21:58 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 |
On 03/03/2011 09:33 PM, Stuart Hughes wrote:
Hi Jurgen,
Some points:
First although it's named lfs-5.1, you should see that as a starting
point (or origin), many package have been updated.
ok
Secondly, there are many packages that are out of date, and it could be
nice to upgrade. However this is a big undertaking unless it can be
automated, there are 400 packages and even if it only took 2 hours per
package (and that's way too low), it's a lot of effort. Currently there
is no one sponsoring any work for the community for LTIB (except some by
Zee2 who I have an association with).
Finally, and more philosophically in many ways LTIB in terms of its
package set has grown way beyond where I originally designed it. The
idea was not to make a distribution, but a tool that builds enough
packages to allow you to bootstrap a new platform and from there if you
want build a full distribution. There are plenty of other full
distributions that have enough resources to do a proper job of
maintenance (Debian). The niche for LTIB is really that it can scale
down to a tiny package set (around 5) which is something few others can
offer. In this context having old packages doesn't matter so much.
indeed
If there were a sponsor, here are the things that could be done:
# ARM QEMU target emulator support (for graphics)
# Web interface to build/add-packages/edit/release
# Documentation/website refresh
# Distribution update - direct from upstream or Debian sources
# Distribution rationalisation - relevant embedded packages
# Patch clearance and release interlock tool
# Use of QEMU to provide pseudo native builds - cross compile enhancement
# Re-factoring BSPs to be self-contained
# Dynamic host support package dependency installs
# Common git based kernel builds with per project branch management
I would like that ;-)!
If I understand it well (I'm just learning ltib), to work on the source
code, you must provide a linux tarball, keep the sources in
ltib/rpm/BUILD/linux, apply your changes, run './ltib -p kernel -m
patchmerge'. This automatically creates a patch file and updates the
.spec file.
But, if I want to commit my patches back to linux, I must use GIT, and
apply the same changes to the git tree, create a patch...
Am I correct?
Kind regards,
Jürgen
# Better multi-core support
# Pre-built binary rpm package feeds
# Investigate supporting non-Linux real-time kernels (RTEMS for example)
Regards, Stuart
On 03/03/11 12:46, Jürgen Lambrecht wrote:
Hello,
why does ltib stay with LFS v5.1, and not upgrade to 6.7?
Is there a reason to?
And if I would want to upgrade, how?
Thanks,
Jürgen
--
Jürgen Lambrecht
R&D Associate
Tel: +32 (0)51 303045 Fax: +32 (0)51 310670
http://www.televic-rail.com
Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium
Company number 0825.539.581 - RPR Kortrijk