A way to export the patches sources in a tarball or package format to assist in license compliance by the end user. Two methods, a system wide export based on the contents of what was use to generate a build (dependency based) and an individual per-package export. Export should include the "run...." files used to perform a build.
Have also heard that people want only the GPL* sources produced.
Hi Mark, The following comment is my understanding about requirement. (In reply to comment #0) > A way to export the patches sources in a tarball > or package format to assist in > license compliance by the end user. > > Two methods, a system wide export based on the contents of what was use to > generate a build (dependency based) and an individual per-package export. > > Export should include the "run...." files used to perform a build. I take core-image-sato for example, The first method: I need export package name and its patches to a file like source_packages.txt the contents are as following: run bash_1.0.bb bash - bash-1.0.tar.gz - 001-bash.patch - 002-bash.patch run man_1.0.bb man - man-1.0.tar.gz - 001-man.patch - 002-man.patch ...... Another method is as following After running the next command $bitbake core-image-sato we will get export information in build/source_package $ls build/source_package bash man ... $cat build/source_package/bash run bash_1.0.bb - bash-1.0.tar.gz - 001-bash.patch - 002-bash.patch I don't know whether my understanding is right or not. Please give me your suggestion and detailed description.
The output of the export could be in two different formats. The first, usually preferred format for vendors in open source compliance, is to export the patched source tree. This would be equivalent to running do_patch, and then tarring up the result and making it available. (I'm not sure if we have a standard location for exporting data, but it seems somewhat logical to me to place it into a directory such as deploy/sources.) The name of the tarball should match the name of the recipe as closely as possible. Something like "pn-pv-pr.tar.<compression>" Allowing the user to specify the compression to use would also be beneficial. The second format is as you described in the previous email. This is a more open source friendly format to be able to share the sources and patches with out people. Doing as you described would be good. The key thing is that the exported sources -must- match the sources used to construct the system for compliance. Another option that would be nice, but not required under this request is a way (during rootfs construction) to write out a manifest file that listed all of the sources used to construct the filesystem. (note: this may be considerably smaller then the list of sources required to build the system.) At least with RPM, this is fairly easy to computer by simply checking with the packages as to their origin "source package". I'm not sure if the correlation can be done more generically.
Duplicated to 1590, and wenzong is working on it. *** This bug has been marked as a duplicate of bug 1590 ***
(In reply to comment #0) > A way to export the patches sources in a tarball or package format to assist in > license compliance by the end user. > > Two methods, a system wide export based on the contents of what was use to > generate a build (dependency based) and an individual per-package export. > > Export should include the "run...." files used to perform a build. Hi Mark, This requirement has been marked as duplicated with #1590, for #1590 we should export the build scripts that '.../temp/run.do_*'. So I just want to make sure with you: Do you mean the 'run....' files are the 'temp/run.do_*'? Please correct me if I got a misunderstand. Thanks Wenzong
Ahh, I'm not sure this is an exact duplicate of 1590. The way I read 1590, we wanted to export the work directory itself so that people could view the sources, intermediate files, logs, etc..... But if we narrow that description to include only sources and patches then I agree it's a duplicate. There is a second item here though, that is exporting the sources in a package format. This format could be debian style tar.gz or SRPM. In this way, people have requested the source to be in a specific format, and the run files indicate how things were built. So for instance in the SRPM case, you would: * List all of the SRC_URI files as sources and patches * in the %prep section Include the run log for do_unpack and do_patch * Perhaps even adjusting it to use RPM style syntax for unpack and patch * in the %build section Include the run log for do_configure, and do_compile * in the %install section Include the run log for do_install The purpose of this is to provide in a package format something that a person can extract and understand how to reproduce the sources, and potentially rebuild the package. It's unlike the run files will be enough to actually perform the build tasks, but the information is the requirement over it actually working. (Some licenses have been interpreted as requiring how to build, as well as the source code.) ---- What I will do is re-open this bug and focus it entirely on producing source packages. The bug 1590 should be adjusted to include the run information. That will resolve the majority of the requirements for this issue. I'd suggest that any source package work be lower priority then the tarball version of the export.
> This requirement has been marked as duplicated with #1590, for #1590 we should > export the build scripts that '.../temp/run.do_*'. So I just want to make sure > with you: > > Do you mean the 'run....' files are the 'temp/run.do_*'? > > Please correct me if I got a misunderstand. Sorry forgot to clarify in the last comment. Yes when I mention the run logs or run files.. I am referring to the temp/run.do_* files.
(In reply to comment #6) > There is a second item here though, that is exporting the sources in a package > format. This format could be debian style tar.gz or SRPM. In this way, people > have requested the source to be in a specific format, and the run files > indicate how things were built. > > So for instance in the SRPM case, you would: > > * List all of the SRC_URI files as sources and patches > > * in the %prep section > > Include the run log for do_unpack and do_patch > * Perhaps even adjusting it to use RPM style syntax for unpack and patch > > * in the %build section > > Include the run log for do_configure, and do_compile > > * in the %install section > > Include the run log for do_install Hi Mark The following steps are my understanding about the above description. Please correct me if my understanding is different with you. I take example package as an example. $ls example SOURCES SPECS $ls SOURCES/* example.1.0.r1.tar.gz log.tar.gz example1.patch example2.patch <example.1.0.r1.tar.gz include source codes and pathes> <log.tar.gz include temp/log.do_unpack temp/log.do_patch temp/log.do_configure temp/log.do_compile temp/log.install> $ls SPECS example.spec $cat SPECS/example Summary: Export source package from work Name: example Version: 1.0 Release: r1 License: LF Vendor: Linux Foundation Packager: POKY Group: Development/Tools Source: example.1.0-r1.tar.gz Source1: log.tar.gz Patch1: example1.patch Patch2: example2.patch %description An example for export source package from work %prep cat log/log.do_unpack cat log/log.do_patch %build cat log/log.do_configure cat log/log.do_compile %install cat log/log.do_install $rpmbuild -bs example.spec <Create a src rpm example.1.0.r1.src.rpm> $rpmbuild -bp example.spec the content of log.do_unpack and log.do_patch will arise on screen.
(In reply to comment #6) > There is a second item here though, that is exporting the sources in a package > format. This format could be debian style tar.gz or SRPM. Hi Mark, The following part is my understanding. Please comment my thinking method. There are two package format, tar.gz and SRPM if the end user select tar.gz format, then the content is the same as what bug 1590 does. if user adopt src.rpm format, then the content should be same as what I describe in the above reply.
Yes, I think that is the correct approach. It would be nice if the SRPM built the same binaries as the target build, but we're not expecting it. The only thing people have said they expect to work is the -bp stage. BTW for implementation, it may be possible to do this within the existing packages_rpm.bbclass, when the .spec file is generated we fill out the sections as you indicated...
This bug has been marked with new bug 1977 because of existing similar function with other bb class (sourcepkg.bbclass in meta/class, bug 1590, src_distribute.bbclass) We need merge functions in these bb class into a new bb class(archiver.bbclass) for avoiding repetitive work in different bb class. Also sourcepkg.bbclass has some bugs and can't be used in the current version. http://bugzilla.pokylinux.org/show_bug.cgi?id=1977
Not really resolved yet, this is a duplicate of 1977 which is the newer better understood issue. *** This bug has been marked as a duplicate of bug 1977 ***