Re: Next steps to get RPM Fusion running (V2)
On Wed, 5 Nov 2008 08:36:08 +0100, Adrian Reber wrote:
> I would advise against using too many manually created links.
Better patch
> the scripts to support the "os" subdir where necessary (or make the repo
> paths more customisable).
There is a special function in mirrormanager called
trim_os_from_dirname(), which removes anything including "/os" from the
path string before starting to guess to which repository this path might
belong. I would really prefer if I do not have to provide an extra code
path just for the rpmfusion development release. From what I see on my
Fedora mirror the debug directory is never under the os directory and
for rpmfusion this is only the case for the development directory.
Is it possible to change the push script to create the debug directory
next to the os directory and not below it? Is there a reason why it
creates the debug directory at another place for the development
repository?
The answer to that was in my previous reply. Quoted here:
> The old default is
>
> $treeroot/$target/$basearch
> $treeroot/$target/$basearch/debug
>
> with no "os" subdir. That matches Fedora (Updates, Test Updates, EPEL,
> Extras). The "os" subdirs seems to be specific to the "releases"
and
> "development" trees, where the repodata path must be constructed
> differently (e.g. $treeroot/$target/Everything/$basearch/os).
In other words, the development repository (and the "release" trees) paths
are created with a different scheme. Simply defining a "development" dist
in the pushscript config file doesn't achieve that.
In pushscript cvs, the "development" dist (and only the development dist!)
is handled differently now and creates paths like
$treeroot/development/$basearch/os/
$treeroot/development/$basearch/debug/
$treeroot/development/source/SRPMS/
which also matches the Everything release tree AFAICS (except for
the "Packages" directory). I've updated several files in order to not
break the multilib resolver, repoview generator and other scripts.
Customisation beyond that would require config file changes (and the
config file is big enough already due to details about external core
repos and the old ability to use these for repoclosure etc.)