[CentOS-devel] proposal on process to carry distro package patches

[Karanbir Singh]

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.



-- 
Karanbir Singh
+44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh
GnuPG Key : http://www.karan.org/publickey.asc