On Sun, Feb 22, 2009 at 4:56 PM, Adriaan de Groot <groot at kde.org> wrote: > Right now we pull the build infrastructure out of CVSDude, with the Solaris/ > directory of each package tarred up into a SOLARIS-<package>-<version> > tarball; these are uploaded and hosted on bionicmutton. So far that has been > the easiest way to make our packages buildable through specfiles, I think. > What we *do* get, regrettably often, is mismatches between the specfile and > the Solaris tarball -- things get fixed in one place, not in another, or an > updated Solaris tarball isn't uploaded (bear in mind this thing also contains > the patches to be applied to the pristine sources, so it's important). I'd > like to guard against this in future by adding ",<rev>" to the tarball name; > this would at least offer us the possibility of noticing breakage sooner. > > The idea would be: when you update patches or stuff in dude, bump src_rev > (this is the independent specfile revision for the given source version of the > package) to force a new download of a new tarball; this will also show off > when you've forgotten to upload a newly rolled tarball from Dude. > > Comments? > > Patches for this are quite trivial; it's a matter of adding it to the one > Source line in common.spec and then fixing the tools to create properly named > tarballs.
Well, I guess the "right" thing to do would be for packages in Dude which require minimal "patching" to be converted to SPEC, so that the problem of versioning between spec file and dude tarballs can be reduced. Yes, there are some packages in dude (stdcxx, qt) which are unlikely to be able to be easily converted to spec, just because of complexitiies of the patches or said configure scripts, and this versioning idea will go a ways to cleaning that up. I would assume that if I'm actively trying to fix a problem with the build, (and I usually do that by customizing the Solaris tarball), I would bump the dude_src_rev variable in the spec file, and create my new tarball with the matching revision? (I usually symlink to the spec dir the SOURCES, BUILD, BUILDLOGS and PKGS directories, and for custom tarballs, I create those under SOURCES/X<var> so that negotiating back and forth between the specs, the sources and the builds in pretty easy. I know that most of the stuff I've added (texinfo, libvncserver, etc) could probably be converted to pure spec since those required almost no patching. Thoughts? Ben
