On Thu, Nov 06, 2014 at 09:55:30AM +0000, SP wrote:
On 06/11/14 08:55, Magnus Therning wrote:
Specifically, I extract the changed .cabal for pandoc, which only existed in the index file, and put the changes into `patches/pandoc.source`, then I can remove `patches/pandoc.cabal`.
Without experience in this, I was thinking that searching for diffs and automatic patching of the old cabals was one of doing it. But Apparently you don't care for the cabal? I mean it is only for deps anyway mostly right?
The .cabal is of course used to get to the dependencies, but beyond that it's not used for much in `cblrepo`, that's right. Automatic diffing would be one way. I was planning on simply copying in the correct .cabal (found in the index file) from the generated PKGBUILD. In either case the .cabal file has to be extracted from the index at `cblrepo pkgbuild`, something that hasn't been required earlier.
It's not a very good long-term solution, but it makes it workable until I have finished refactoring `cblrepo` so it can deal with the situation more intelligently.
What is coming up?
The plan is to do the following: - modify the database format to hold the x-revision - modify `cblrepo list` to show the x-revision - modify `cblrepo updates` to pull out the .cabal from the index when looking for updates (previously it was enough to just look at the path in the .cabal to determine if an updated package was available) - modify `cblrepo add` to deal with x-revision - modify `cblrepo pkgbuild` to extract the .cabal from the index and generate PKGBUILDs having it as a source and copying it into the build folder, the version number of the packages also should include the x-revision Before all of this I want to rewrite the handling (reading, patching, copying) of .cabal files slightly. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus Code as if whoever maintains your program is a violent psychopath who knows where you live. -- Anonymous