rpmfusion based spin

[Jeroen van Meeuwen]

KH KH wrote:
> 2008/8/27 Rahul Sundaram <metherid at gmail.com>:
>> KH KH wrote:
>>> I don't know if Thorsten ever mention such "spin" but having both
>>> rpmfusion and fedora on the same media is a very hard legal issue.
>>> Actually that's even not possible at all without removing the name
>>> Fedora from such spin. (meaning removing artworks and some others
>>> packages i don't remember)
>> As Jeroen van Meeuwen, this is not a big deal technically as you make it out
> True. It is easier than I thought..
> 
> At least we can first works at the documentation step providing a .ks
> and a "replacement package" for the fedora-logos (outside of the
> RPMFusion repository?)

The Spin SIG is interested in assisting you if you want to, and we in 
turn would appreciate your inquiries because of possible precedents 
being formed. I'm on this list as well so I'm certainly keeping an eye 
on how things are going.

> Most of the work will be between .ks and the comps.xml for default
> packages installation per group.
> 

The kickstart file or kickstart files I presume has two separate 
purposes; one is to create the Live Media with, doing all kinds of 
tweaking and configuration to the soon-to-be-live system -besides the 
package selection, whereas the other purpose of a kickstart is to select 
packages and groups to be included on the Installation Media. FWIW, most 
people use separate kickstart files for these two different types of 
media (live and installation).

These kickstarts could be distributed and included in the 
rpmfusion-release package, which then also gives you a central spot to 
maintain the configuration files. If access to the source tree of the 
rpmfusion-release package is a problem (because you do not want to give 
too many people too much access), maybe GIT submodules can be a solution.

It'll also be interesting to examine how the product can be treated from 
the installation procedure (install media) point of view; there's two or 
three products right now, each having their own little private 
settings/routines for reading repodata from one or more locations, and 
default group selection (or "install types", like "Office & 
Productivity"). Including a product.img during the compose of the 
Installation Media could solve this problem pretty easily, including the 
problem of merging comps.xml (and possible conflicts that arise during 
the merge). Compose tools very efficiently merge comps files from 
different repositories into what ends up to be repodata/comps.xml[.gz], 
but obviously that has some requirements to both comps files. Let's not 
get into those details right now ;-)

I'm also curious how RPMFusion intends, that is if it even viable, to 
compose the "additional media" CD to a genuine Fedora installation media 
(set) as well, since this is a first (and afaik the dialog for using 
additional media after the initial installation has been removed from 
Fedora). This however does not apply to the use case where a genuine 
Fedora installation is installed and running and having a .repo file 
point to the media from RPMFusion, but solely to the installation 
procedure itself.

Kind regards,

Jeroen van Meeuwen
-kanarip