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