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