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
- extract the SRPM
- change the SPEC
- change/add/remove patches and other Sources
- extract the included tarballs if they need to be changed
- apply changes to the tarball content
- repackage the tarballs
- 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
- rpm -i whatever.src.rpm
- cd SPEC && patch < spec-changes.patch; cd ..
- cd SOURCES && patch < source-changes.patch; tar xf sources.tar; cd ..
- gzip -cd whatever-1.2.3.tgz | tar xCf /tmp -
- cd /tmp/whatever-1.2.3 && patch < tarball.patch; tar xf tarball.tar
- cd /tmp tar cf - whatever-1.2.3 | gzip -c9 > whatever-1.2.3.tgz
- 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@solvention.de _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel