On Monday 23 February 2009 14:43:54 you wrote: > 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. > > 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.
That is exactly what JDS (and other specfiles setups) do. The current setup wins for consistency across all the packages, though, because we've got a good definition of a standard environment for things to build in. I was planning actually to go after giflib to start with, since (a) that's really simple (b) it's a requirement for Qt. > 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. The %prep %build %install sections of the specfile correspond exactly to the scripts we have, and since it's a standard shell environment you can do all the same things there. A little more, actually, since you also have the pkgbuyild variables available, so things like if test $has64 = "yes" become %if %_has64, removing one level of indirection. [[ Other topic: ]] > 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, Just src_rev, and yes, that's exactly right. Same version of the (upstream) software, newer version of the package because you've done more porting or bugfixing. > and create my new tarball > with the matching revision? Yes. As a rule of thumb I'd say when you commit a change to the Solaris/ dir of something in the Dude repo, bump the src_rev as well. Then use 'make tar-<package>' to re-roll the Solaris tarball and upload it to bionicmutton. As a side effect, this also means that we'll have fewer permissions collisions as people don't have to overwrite the Solaris-<foo>- <rev> tarball each time they change something -- you get a new src_rev.
