From Fedora Project Wiki
(→‎Potential Problems and Enhancements: add some real world pacakge problems)
 
Line 48: Line 48:
: KDE packages seem to have a create_tarball.rb script, which should be used probably --[[User:Till|Till]] 18:17, 11 March 2010 (UTC)
: KDE packages seem to have a create_tarball.rb script, which should be used probably --[[User:Till|Till]] 18:17, 11 March 2010 (UTC)
* A parameter to specify to include only certain paths from the repo might be useful. --[[User:Till|Till]] 18:09, 11 March 2010 (UTC)
* A parameter to specify to include only certain paths from the repo might be useful. --[[User:Till|Till]] 18:09, 11 March 2010 (UTC)
* The maven format seems to miss important features like a way to specify a branch, tag or revision (when speaking about git).  I suggest to learn from a system which fetches from SCMs for years: bitbake.  There can be written
  git://git.somewhe.re/foo.git;proto=http;branch=abc
  git://git.somewhe.re/foo.git;proto=rsync;tag=XYZ
[[User:Ensc|Ensc]] 08:28, 30 July 2010 (UTC)


== Further Discussion ==
== Further Discussion ==

Latest revision as of 08:28, 30 July 2010

Warning.png
This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

Executive Summary

This proposal is to add an informative comment to the Fedora spec files, of the form:

#VCS: <vcstype>:<vcsurl>

Example:

#VCS: git:git://git.gnome.org/metacity

Rationale

Currently spec files have a lot of metadata about the upstream project; however it lacks one of the most important, which is the upstream revision control system.

Adding this data will allow:

  • Cherrypicking a patch directly from the upstream VCS
  • Correspondence checking between source tarballs and VCS checkouts
  • Automated build scripts to update the spec from VCS
  • In the more distant future, reworking Fedora's packaging to be more VCS-centric (i.e. having a mirror of upstream VCS instead of series of inefficient tarball snapshots in lookaside cache)

Implementation

Because RPM only allows a well-known set of keys, this proposal introduces the key with a comment prefix, to ensure that older RPM versions do not complain. A patch has been [submitted upstream] however.

The key format has been influenced by the [Maven SCM format], however we drop the redundant "scm:" prefix.

Supported implementation formats:

git

The <vcsurl> part should be in a format which git clone as of Git 1.6.6 will accept, with the additional qualifier that the URL may have a fragment identifer which denotes a branch. Examples:

#VCS: git:http://example/~you/proj.git
#VCS: git:git://git.clutter-project.org/clutter#clutter-1.0

Potential Problems and Enhancements

  • Some packages do not have a direct correspondence between source tarballs and version control (e.g. translations come from somewhere else)
This might be addressed with supporting several VCS-keys. Example packages would be helpful here. --Till 18:09, 11 March 2010 (UTC)
Problematic packages from the FESCo ticket: Amarok, Konversation: Source from gitorious, translations from svn, TIGCC uses two CVS repos and some directory --Till 18:17, 11 March 2010 (UTC)
  • There are a wide variety of version control systems in use, and it's an open question to what extent we should "support" the more obscure ones
Everything for what patches are submitted should be supported imho. --Till 18:09, 11 March 2010 (UTC)
  • I would like the key to be #VCS0 to show that it corresponds to Source0 --Till 18:09, 11 March 2010 (UTC)
  • For non autotools packages that require some post processing, it would be helpful to be able to add a pointer to a specific post-processing script, e.g. one that is included as SourceXY --Till 18:09, 11 March 2010 (UTC)
KDE packages seem to have a create_tarball.rb script, which should be used probably --Till 18:17, 11 March 2010 (UTC)
  • A parameter to specify to include only certain paths from the repo might be useful. --Till 18:09, 11 March 2010 (UTC)
  • The maven format seems to miss important features like a way to specify a branch, tag or revision (when speaking about git). I suggest to learn from a system which fetches from SCMs for years: bitbake. There can be written
 git://git.somewhe.re/foo.git;proto=http;branch=abc
 git://git.somewhe.re/foo.git;proto=rsync;tag=XYZ

Ensc 08:28, 30 July 2010 (UTC)

Further Discussion

Unfortunately, some questions were raised here: https://fedorahosted.org/fesco/ticket/353 Wait until that dies down and then make sure those questions get asked and addressed here.