Re: rpmfusion based spin
KH KH wrote:
2008/8/27 Rahul Sundaram <metherid(a)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