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