From: Xiaofeng Yan <xiaofeng.yan@windriver.com>
To: Saul Wold <sgw@linux.intel.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [oe] Source Archiver Class
Date: Mon, 13 Feb 2012 18:41:15 +0800 [thread overview]
Message-ID: <4F38E8CB.6090101@windriver.com> (raw)
In-Reply-To: <4F24F672.5090107@linux.intel.com>
Hi Saul,
I have some issues when I writing design document. The following
description is my understanding. I take package "zlib" for example .
>
>
> This is a progression list of what the source archives should include:
>
> 1 - Original Upstream Archive & Patches
> - 2 archives (tarballs)
$ls zlib-orgsource
zlib-1.2.5.tar.bz2(after do_fetch)
zlib-patches.tar.bz2( the patches come from
meta/recipes-core/zlib/zlib-1.2.5)
> 2 - Original Source code & Patches
> - could include additional code
Please give me more detailed information
> - post unpack
> - 1 archive
$ls zlib-orgsource
zlib-1.2.5.tar.bz2(after do_unpack, patches are not included in this
package.)
No patch in this directory.
>
> 3 - Original Source code & Patches & temp (scripts & logs)
> - Could possibly include the .bb and .inc files
> - 2 archives (from #2 & temp tarball)
$ls zlib-orgsource
zlib-1.2.5.tar.bz2(after do_unpack, patches are not included in this
package.)
zlib-patches.tar.bz2( the patches come from
meta/recipes-core/zlib/zlib-1.2.5)
zlib-scripts-logs.tar.bz2(include zlib_1.2.5.bb,zlib.inc and tmp/log_*)
So there are 3 tarballs in this directory.
> 4 - Patched source code
> - original source code could be removed
> - post do_patch
$ls zlib-source
zlib-1.2.5.tar.bz2(after do_patch)
> 5 - Patched source code & temp
> - 2 archives (from #4 & temp tarball)
$ls zlib-source
zlib-1.2.5.tar.bz2(after do_patch)
zlib-logs.tar.bz2(include tmp/log_*)
> 6 - Configured Source
> - post do_configure
$ls zlib-source
zlib-1.2.5.tar.bz2(after do_configure)
> 7 - SRPM format of Original Source & Patches
> - rpm will apply the patches
> - internally contains #2 above
$ls zlib-srpm
zlib-1.2.5.src.rpm
zlib-1.2.5.src.rpm includes zlib-1.2.5.tar.bz2(after do_unpack, patches
are not included in this package.) and zlib-patches.tar.bz2
> 8 - SRPM various of #3 above
$ls zlib-srpm
zlib-1.2.5.src.rpm
zlib-1.2.5.src.rpm includes zlib-1.2.5.tar.bz2(after do_unpack, patches
are not included in this package.) ,zlib-patches.tar.bz2 and
zlib-scripts-logs.tar.bz2
Do you have any suggestion about the above description?
Thanks
Yan
> ...
> 100 - Buildable SRPM
> - can actually build, this is way future!
>
> (Patches = patch files & series list)
>
> Each of these build on the previous in some way, the key being that we
> generate a tarball for the source from the existing state of the
> WORKDIR, a challenge maybe to create the source snapshot after the build
> has already occurred.
>
> The SPDX License info could also be included in any of these
>
> After talking with Richard, we think we have a novel approach to make
> this work. It would entail using the postfuncs feature similar to the
> way that Shared State does it's work. The existing copyleft_compliance
> class functionality can be folded into this as a filter. Additional
> flags could be passed from individual classes to a core set of methods
> in an archiver class defining the type of data (source, patches, temp,
> env, recipe info, ...) and format (tar, sprm, ...)
>
> I noted that recipe type code might be better suited as generic code, as
> I believe there are other places that could benefit from that code.
>
> The sourcepkg class seems to be a basic archiver and differ that
> includes the metadata/environment (as dumpdata), this could be replaced
> by the new approach. While the src_distribute class copies the
> downloaded archive and then creates a link, into LICENSE directories
> along with the patches. The src_distribute by default seems to move
> files and create links (incorrectly btw!). This work can be done by the
> archiver class.
>
> The Nugget: Create a new core "archiver" class that implements a general
> functions that can archive the original tarball or workdir at various
> states along task list with additional metadata (recipe info, temp dir,
> environment). This class would be inherited by a set of classes that use
> the postfunc (similar to sstate) that setup what level of archive is
> needed (based on the list above).
>
> Thoughts, Comments?
>
> Thanks
>
>
>
next prev parent reply other threads:[~2012-02-13 10:49 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-26 20:56 Source Archiver Class Saul Wold
[not found] ` <4F24F672.5090107@linux.intel.com>
2012-02-13 10:41 ` Xiaofeng Yan [this message]
2012-02-14 16:51 ` [oe] " Saul Wold
2012-02-15 15:23 ` Saul Wold
2012-02-16 1:19 ` Xiaofeng Yan
2012-02-17 23:52 ` Saul Wold
2012-02-20 6:40 ` Xiaofeng Yan
2012-02-21 16:57 ` Saul Wold
2012-02-23 2:24 ` Xiaofeng Yan
2012-02-23 2:41 ` Chris Larson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F38E8CB.6090101@windriver.com \
--to=xiaofeng.yan@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=sgw@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.