hi,
https://git.centos.org/tree/sig-core!bld-seven.git mirrored at : https://github.com/CentOS/sig-core-bld-seven
now carries a proposed process to carry package patches. So stuff like branding or build changes needed, or even content changes to make things work could be carried like this. Primary target is for people doing arch work that isnt inherited from upstream.
Comments welcome, were only going to start with this for the i686 builds, but if it works and is acceptable widely, we can roll this out across the board.
- KB
On Tue, 4 Feb 2014, Karanbir Singh wrote:
hi,
https://git.centos.org/tree/sig-core!bld-seven.git mirrored at : https://github.com/CentOS/sig-core-bld-seven
now carries a proposed process to carry package patches. So stuff like branding or build changes needed, or even content changes to make things work could be carried like this. Primary target is for people doing arch work that isnt inherited from upstream.
Comments welcome, were only going to start with this for the i686 builds, but if it works and is acceptable widely, we can roll this out across the board.
- KB
How does this system handle the following cases :
disttag changes compared to default
Patch for SIG 1 vs SIG 2 for the same package. What determines what SIG a patch is for?
How to handle "disabling" a patch for a package. i.e. plymouth disabling "everything is red"
How are changelogs noted for these patches since they require a spec file change?
What determines the new "version-release" ?
How does one patch against an older "version-release"?
How does one patch against a prior "SIG" patched version?
Can I automatically apply a patch to the newest version of package A no matter what has changed. I.E. apache "default index.html"
Why separate i386 and x86_64 patches ?
-Connie Sieh
hi,
On 02/04/2014 05:50 PM, Connie Sieh wrote:
How does this system handle the following cases :
disttag changes compared to default
the disttab is forced to include a '.centos' for every package that is patched. if the hints file has something, it overrides this, otherwise <dist>.centos is forced into the mock configs, ofcourse if the spec file does not consume disttag macro, that isnt going to do anything ( but the resulting rpms will fail the buildrelease tests, since they are now expected to have centos in the name ).
Patch for SIG 1 vs SIG 2 for the same package. What determines what SIG a patch is for?
these patches are for the core-sig distro only. I would expect SIG's maintaining forks / branches of packages to do their work in git directly. At that point, it might be interesting to see how we can forward merge based on core-distro updates.
How to handle "disabling" a patch for a package. i.e. plymouth disabling "everything is red"
the patch is applied to the rpmroot dir of the package, pre-build, once its setup to build, so removing things should be easy, just a bunch of -'s
How are changelogs noted for these patches since they require a spec file change?
the date field is auto injected along with the last committer to the patch file, the commit message is used for the changelog entry. I've not found an easy way to indicate the ver-rel in the changelog date line, so skipping that for now.
What determines the new "version-release" ?
this is just a rpm macro eval, if the patch is only needed for a specific version-release.arch, then it should be named so ( but I suspect most patches are going to be for package-name.arch, sine they would need to apply accorss all updates )
How does one patch against an older "version-release"?
the patch will apply whenever something builds, so in order to get an older srpm patched, you'd need to re-request the build. its possible to have an arbitary number of builds with the same n-e:vr.src.rpm since the build tag's are date driven, and only the most recent one is used. Even the manifest parser will do something like find <root> -name <blah> | sort | tail -n1 : so we only get the last built one.
buildtags are auto generated, so its not possible to 'tweak' then into the past.
How does one patch against a prior "SIG" patched version?
does the previous answer cover this as well ?
Can I automatically apply a patch to the newest version of package A no matter what has changed. I.E. apache "default index.html"
thats the plan, these patches apply automatically. we need to find someway to test that the patch applied in some cases; and in other cases, we might need to execute a script ( eg. to consume the mozilla-prefs.js and split out the patched version ), but lets cross those bridges when we neet to.
Why separate i386 and x86_64 patches ?
the arch split is optional, its there for patches that only need to apply for one arch ( hunspell for example has a x86_64 bin included in the srpm.. ) or for other places ( eg. aarch64 or arm32 or powerpc )
parsing, optionally, the arch as well just makes it possible to not need to patch all arch's due to something that is only needed on one arch.
-
Connie Sieh -
Karanbir Singh