[Yum] RFC: Linking of Repositories

Dominique Leuenberger Dominique.Leuenberger at TMF-Group.com
Mon Nov 13 09:15:08 UTC 2006


>>> Reply on 13-11-2006 11:09:24 <<<> Dominique Leuenberger wrote:
> >  > > > The issue for this mail is caused by the Packages of the
> > > UFO:AI,
> > > > > which has a 160MB Data (thus noarch) RPM.
> [snip]
> > > > > os/arch-independent (data) part. As the data part is
> big
> > > > > (160MB) it's a waste to replicate that one for all OS
> > > and
> > > > > fill servers with it.
> Perhaps I miss the point here, but I don't see why you can't just
> create
> separate repositories?
> Say you have x86 and x86_64. Then you would create 3 repositories :
> - one for binary x86
> - one for binary x86_64
> - one for game data (noarch)

The binaries are kept in the same repository on the openSUSE Build
Service (A package build cluster). For the moment, this package (but the
request also concerns other packages!) is built for 3 distributions,
more to come.
The gamedata should be in a separate repository for not having it to
Adding the game data repository AFTER installing the game binary to the
system would render the installation of the game binary useless, until
the user MANUALLY adds the Game Data to the computer. It would not be
possible to have a Requires: gama-data in the binary (which of course is
highly required for a good user experiance)
There were several discussions on the Mailinglist of openSUSE, and no
solution really revealed a good user experiance. Except what we brought
up here: While adding a repository, a metalink to another repo should
exist to have added a second one with other mandatory packages.
Just as another example:
 Somebody else wanted to build Amarok against KDE 4 (which is highly
experimental at this time). a KDE4 Test repo for openSUSE already
exists. So he would create a repo with HIS Amarok Packages, and the repo
would have a metalink to the existing KDE4 repo. When The AMA-Repo get's
added, the KDE4 repo automatically get's added too.
And I'm quiet sure there are more cases like this out in the world.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.baseurl.org/pipermail/yum/attachments/20061113/740e143b/attachment-0001.htm 

More information about the Yum mailing list