[CentOS-devel] Reality V/s Fantasy

[Jeff Johnson]

On Dec 3, 2010, at 10:24 AM, Andreas Rogge wrote:


Hi Andreas!

> 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".

(aside)
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
something changes).

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).
> 

CC done

hth

73 de Jeff

> Regards,
> Andreas
> 
> -- 
> Solvention Ltd. & Co. KG
> Egermannstr. 6-8
> 53359 Rheinbach
> 
> Tel: +49 2226 158179-0
> Fax: +49 2226 158179-9
> 
> http://www.solvention.de
> mailto:info at solvention.de
> _______________________________________________
> CentOS-devel mailing list
> CentOS-devel at centos.org
> http://lists.centos.org/mailman/listinfo/centos-devel