Edit Info Other
Login

Diff for "FoundingPrinciples"

Differences between revisions 5 and 6
Revision 5 as of 2007-03-02 15:17:39
Size: 2443
Editor: HansdeGoede
Comment:
Revision 6 as of 2007-03-02 16:34:17
Size: 2453
Editor: MatthiasSaou
Comment:
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
 process for new submissions, Fedora's VCS structure, Fedora's buildsys  process for new submissions, Fedora's VCS structure, Fedora's build system
Line 28: Line 28:
 the kmod(FE) dkms(freshrpms) or kdmls(atrpms) kernel module packaging schemes (2). A module may  the kmod (fedora) dkms (freshrpms) or kmdls(atrpms) kernel module packaging schemes (2). A module may

rpmfusion founding principles

Before we start working on technical details, I think its very important to have a set of founding principles, much like the "Core Principles" of fedora: http://fedoraproject.org/wiki/Objectives

I've split the principles into 2 sets for now, one we all agree on, and one for principles which are still under discussion.

Principles we all agree on

  • The new repo will follow Fedora where possible. This means using Fedora's packaging guidelines (except for legal), Fedora's review process for new submissions, Fedora's VCS structure, Fedora's build system etc.
  • The main new repo will contain add-on packages and not replacements in relation to the base package set. Whereby the base package set is defined as: RHEL/centos + EPEL (1) or Fedora (Fedora 7+) or Fedora Core + Fedora Extras (Fedora 6-) As an exception, with proper motivation replacements are allowed, but the replacements and any packages requiring the replacements will be in a seperate repo which will NOT be enabled by default.
  • rpmfusion will contain kernel module packages in the main repo

Principles under discussion

  • kernel packages maybe packaged using the kmod (fedora) dkms (freshrpms) or kmdls(atrpms) kernel module packaging schemes (2). A module may be made available for more then one scheme. But the "Name: " tag of the packages must be unique, if this currently is the not the case then the maintainers of the conflicting packages will work this out together. Also different packages of the same module must explicitly Conflict each other.

Footnotes

(1) While EPEL is not available, we will assume an empty EPEL repo. As EPEL gets populated we will work together with EPEL to avoid conflicts/overlaps. This also means that where dependencies for certain packages are missing we will provide these by rebuilding (and adapting where nescesarry) those bits from Fedora.

(2) This means that plague must be modified to support al these, or even that we may use a different buildsystem altogether if thats easier, as long as the buildsystem uses mock with the fedora minimal buildroot.

Notice that this doesn't mention how we are actually going todo anything yet, nor with which base distro releases we will start. This is intentional as these (important) details are not part of our founding principles.

FoundingPrinciples (last edited 2023-11-14 09:37:58 by anonymous)