[Starlingx-discuss] [Build] Question about meta_patches
Hi all, As I understand, the meta_patches are patches that are applied to the specfiles for projects where a SRPM is downloaded. This process is something like: - Unpack srpm - Apply patches to the <project>.spec file. Most of this patches are just modifications to add source code patches. - Create a new srpm with the source, the modified specfile and additional patches that will be applied on build time. So, having this process, I'm wondering in the need of having the meta_patches instead in just one <project>.spec checked in the repository. Also, I'm trying to understand the rationale behind these meta_patches. Thank you in advance. -Erich
Not just the spec file, but any other files not in the upstream tarball. E.g. centos specific config files. 1) It works for srpms from all sources. Including those that don't publish a git of their spec files and other meta-data. 2) It yields a very clean boundary between what was 'ours' and what was 'others'. Made the lawyers happy. 3) Before we switched to the 'repo' tools, we had to keep all repos using a common branch name. This created a strong incentive to keep the number of gits to a minimum. On 18-11-01 07:01 PM, Cordoba Malibran, Erich wrote:
Hi all,
As I understand, the meta_patches are patches that are applied to the specfiles for projects where a SRPM is downloaded. This process is something like:
- Unpack srpm - Apply patches to the <project>.spec file. Most of this patches are just modifications to add source code patches. - Create a new srpm with the source, the modified specfile and additional patches that will be applied on build time.
So, having this process, I'm wondering in the need of having the meta_patches instead in just one <project>.spec checked in the repository.
Also, I'm trying to understand the rationale behind these meta_patches.
Thank you in advance.
-Erich _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
On Mon, Nov 5, 2018 at 9:48 AM Scott Little <scott.little@windriver.com> wrote:
Not just the spec file, but any other files not in the upstream tarball. E.g. centos specific config files.
1) It works for srpms from all sources. Including those that don't publish a git of their spec files and other meta-data.
2) It yields a very clean boundary between what was 'ours' and what was 'others'. Made the lawyers happy.
3) Before we switched to the 'repo' tools, we had to keep all repos using a common branch name. This created a strong incentive to keep the number of gits to a minimum.
On 18-11-01 07:01 PM, Cordoba Malibran, Erich wrote:
Hi all,
As I understand, the meta_patches are patches that are applied to the specfiles for projects where a SRPM is downloaded. This process is something like:
- Unpack srpm - Apply patches to the <project>.spec file. Most of this patches are just modifications to add source code patches. - Create a new srpm with the source, the modified specfile and additional patches that will be applied on build time.
So, having this process, I'm wondering in the need of having the meta_patches instead in just one <project>.spec checked in the repository.
Also, I'm trying to understand the rationale behind these meta_patches.
Thank you in advance.
-Erich _______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
HI I am new to the project and i would like to ask some basic questions related to this topic from what i have seen in other projects: a) I love the idea of having one git repository per project where the spec files , sources , patches and more could live (something that we discuss last week with Erich) . In the long/short future if we support other OS based on deb files we could have a directory : rpms_base and deb_baase. However i would like to ear some feedback ( pros and cons ) from the STX community What to do after this is open to the community many tools to build from a single git repository are living today out in the opensource ( koji / obs/ you name it ) But before that ( and in a separate mail ) i would like to hear the feedback about this idea Regards Victor Rodriguez
participants (3)
-
Cordoba Malibran, Erich
-
Scott Little
-
Victor Rodriguez