[CentOS-devel] Reality V/s Fantasy
n3npq at mac.com
Fri Dec 3 10:38:11 EST 2010
On Dec 3, 2010, at 10:24 AM, Andreas Rogge wrote:
> Am 02.12.2010 22:54, schrieb Ralph Angenendt:
>> Am 02.12.10 10:31, schrieb Florian La Roche:
>>> Hello KB,
>>>> One of the main things that the QA team needs to work with is
>>>> whitelisting for release, the branding stuff. That intself means the qa
>>>> team needs to stay small, non public access to early code builds. Also
>>> Red Hat distributes the source without restrictions and e.g. kernel.org
>>> is mirroring it out on all its mirror systems, so there is no requirement
>>> to keep the CentOS source hidden due to branding/whitelisting issues AFAIK.
>> Hmmm. They are redistributing RH code. We try to do that as a different
>> project. So yes, you might be right, but I'd really like to not step
>> onto someone's toes inadvertently :)
> We don't need to redistribute the original files. We could make up a way
> to have "patches" for SRPMs.
> What you do when changing an SRPM is usually the following:
> 0. download the SRPM
> 1. extract the SRPM
> 2. change the SPEC
> 3. change/add/remove patches and other Sources
> 4. extract the included tarballs if they need to be changed
> 5. apply changes to the tarball content
> 6. repackage the tarballs
> 7. repackage the SRPM
While one can easily imagine the necessary procedure to "patch"
build recipes, its actually a quite painful process to maintain
in the "real world".
Applying meta-patches has been attempted with WindRiver Linux,
rather a disaster (imho, there are other benefits to WRL, just
not the meta-patching of build recipes). All JMHO, YMMV.
> Afaict this is all scriptable.
> 0. wget http://whatever.url/the/file/is/located/at.src.rpm
> 1. rpm -i whatever.src.rpm
> 2. cd SPEC && patch < spec-changes.patch; cd ..
> 3. cd SOURCES && patch < source-changes.patch; tar xf sources.tar; cd ..
> 4. gzip -cd whatever-1.2.3.tgz | tar xCf /tmp -
> 5. cd /tmp/whatever-1.2.3 && patch < tarball.patch; tar xf tarball.tar
> 6. cd /tmp tar cf - whatever-1.2.3 | gzip -c9 > whatever-1.2.3.tgz
> 7. rpmbuild --nodeps -bs whatever.spec
Its not the scriptable, but rather the process framework to
apply the meta-patch to the build recipe that is the torquemada.
> I'll admit that it isn't that simple, but we could have a system to keep
> "SRPM patches" around and as these won't contain RH trademarked stuff it
> won't hurt.
> The to-be-patched SRPMs can be fetched by anyone from the original
> source which is also ok.
> As you might have noticed I'm suggesting to unpack tarballs into
> existing directories. This is to overwrite and replace existing and
> "offending" RH stuff. Files that should be removed can simply be
> overwritten with 0-byte files (I guess nobody can sue us for a filename
> in a tarball)
There are hints here to what tends to called "exploded SRPM's" in
my vocabulary, basically don't bother with all the rituals of
Sources + Patches + Recipe == Reproducible builds
from last century still in use with RPM, but just build straight
from a VCS like git/svn.
One immediate benefit with "exploded SRPM's" is that you can start
to use grep to find what needs changing, and a VCS to track patches
(rather than re-stacking patchsets and other tedious chores when
All of "exploded SRPM's" is quite doable and KISSier. But you likely
are stuck with whatever @redhat chooses to do. Oh well ...
> If something like this is appreciated I could write example-scripts to
> do the work.
You might want to look at WRL: they essentially have a *BSD ish "make world"
framework on top of traditional rpmbuild invocations. The design (because
it refactors per-package goop into a per-buildsys framework) is perfectly
sane even if the reults (imho) are rather awkward for "package monkeys".
> btw. please CC responses to me (I don't want to take this off-list, I'm
> just not reading regularly enough to catch responses in time otherwise).
73 de Jeff
> Solvention Ltd. & Co. KG
> Egermannstr. 6-8
> 53359 Rheinbach
> Tel: +49 2226 158179-0
> Fax: +49 2226 158179-9
> mailto:info at solvention.de
> CentOS-devel mailing list
> CentOS-devel at centos.org
More information about the CentOS-devel