On Thu, 2008-11-06 at 00:58 +0100, Michael Schwendt wrote:
On Wed, 29 Oct 2008 19:29:47 +0200, Jonathan Dieter wrote:
> Whichever machine builds the deltarpms needs loads of RAM (mainly for
> the really big rpms). Specifically, you need (uncompressed_size_of_rpm
> * 3).
>
> Other than that, not much
Might be the blocker criterion, however.
Yeah, fair enough. I've only got 1GB of RAM on the server that's
hosting the test repositories, so when I get alienarena-data updates
(and the like), I just manually kill the makedeltarpm process. Less
than optimal, I know
> Yes, though if you're doing rpmfusion-free and
rpmfusion-updates-free,
> ATM that path needs to be a parent directory of both. In the test
> repositories, I kludge it by making a rpmfusion+updates-free that
> contains symlinks to rpmfusion-free and rpmfusion-updates-free. (If
> that's not clear, check out the directory layout in
>
http://lesloueizeh.com/f9/i386 and you should see what I mean.)
Creating a tmp dir that contains symlinks to the repos would work?
Yes.
Another hurdle is that the rpmfusion-free repo (= releases ->
Everything)
is not maintained within the pushscript configuration file. Only
updates and updates-testing are. Example:
'9' is the dist id for the RPMFusion F9 updates
'testing/9' is the id for the corresponding test updates
The absolute/relative path to the releases/9/Everything repo tree would
need to be added via new config values. Not a big problem, though.
Yeah, that makes sense. Again, if you add a new config value for the
rpmfusion-release directory and create a temp directory with symlinks to
rpmfusion-release and rpmfusion-updates, it will work fine.
On a side note, I don't mirror updates-testing at all, so I haven't
worked out the best way to do deltarpms for updates-testing. Obviously,
regenerating all the deltarpms when moving a package from
updates-testing to updates doesn't make a whole lot of sense, but just
copying the deltarpms over may not work properly either (you might have
deltarpms from rpms that never made it into updates).
> Yes, that looks *way* simpler than the proposed method in
Fedora.
I've
> got some time tomorrow; I'll see what I can come up with.
I've set up some files to test presto-utils here.
One thing that doesn't want to work is 'createprestorepo -m <repo
dir>'.
It says "Delta directory must exist." which is nothing I understand
without examining the source code.
Yeah, that's because the createprestorepo programmer is lousy at keeping
his documentation up-to-date. Oops. The correct usage of
createprestorepo is 'createprestorepo <base dir> <location to put
prestodelta.xml>'. Then you use modifyrepo to insert prestodelta.xml
into repodata.
Sorry about that.
Jonathan