ltib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] XFree86 package


From: Stuart Hughes
Subject: Re: [Ltib] XFree86 package
Date: Thu, 16 Aug 2007 10:14:02 +0100

On Wed, 2007-08-15 at 12:54 -0400, Peter Barada wrote:
> On Wed, 2007-08-15 at 16:39 +0100, Stuart Hughes wrote:
> 
> > I hope to do a complete re-merge update before the end of September, but
> > that depends a lot on how my other project progresses.  If you're using
> > an ISO image from Freescale, you already have these updates.  The reason
> > I haven't merged out is because I want to do some major re-structuring
> > before I do so and didn't want to confuse people with 2 big updates.
> > The purpose of the re-structure is to move all the BSP specific parts
> > (kernel spec files mostly) into the config/platform/<target> directory.
> > This would separate out the LTIB tool from the platform part completely.
> > The idea being that maintenance is easier and "writing a new BSP" is
> > simplified to just adding a new directory with a few files.
> 
> I was going to ask if you also intend to have u-boot spec/patch files in
> the config platform directory as well, but as I was thinking about it,
> instead, can you generalize things so that the config/platform/<target>
> directory is searched first for spec/patch files
> before /opt/freescale/pkgs and dist/lfs-5.1?
> 
> This would allow collecting *all* the changes necessary to support a new
> platform/BSP into the config/platform/<target> directory.  It also would
> allow a BSP to supply not only brand new packages, but also patches and
> spec files for system packages.  As an example, on a board I'm working
> with, it has a video chip that is little-endian with a processor that is
> big-endian.  To complicate matters, its alpha verison has 3/3/3 pixels
> in a 16-bit word, soon to change to 5/5/5.  This requires changess to
> microwindows to support this pixel layout as well as pixel access (has
> to be 32-bit access to modify just a 16-bit pixel, odd pixels in most
> significant short of a 32-bit word, even pixels in least significant
> short of a 32-bit word).  Rather than having patch files that may affect
> other targets, my changes would be isolated to just my target.
> 

Hi Peter,

The u-boot spec files (and any other board specific spec files) will be
moved to config/platform/<target>.  Note that this directory is already
searched first when looking for spec files.  Note also that if you need
to use a different version of a package, you can do this by putting an
entry in the pkg_map file in the config/platform/<target> directory

I don't intend to put any sources/patches into config/platform/<target>.
The reason is that I want to keep the references to the data and the
data itself separate.  This is because:

* Patches are derived from changes and sources themselves and so I don't
want to place derived data under SCM management.

* By forcing patches into a common area (http://bitshrine.orf/gpp 
 /opt/ltib/pkgs ) it means that every patch must be uniquely named.
This means that patch xyz can always relied upon to have the same
content in the same way that <pkg-version>.tar.gz can be.

Regards, Stuart









reply via email to

[Prev in Thread] Current Thread [Next in Thread]