[repo-coord] PyVault Nomenclature

[Jeff Pitman]

All:

I'm throwing out a very alpha version of document that will list some 
guidelines about naming.  For versioning, I'll try to stick with what's 
mainstream (ie, python2.3-2.3.3-3.pyv.0.rh90).  Take a look and bombard 
me with your feedback.  This repo is meant to be, in legacy redhat, 
separated from all other versions of Python.

I'm also considering a python1.5 compat package for later distros that 
have dropped it.

take care,
-- 
-jeff
-------------- next part --------------
  PyVault Naming Standard
  Jeff Pitman
  20 April 2004

  Herein contains information regarding how the PyVault repository will
  name packages, and the standard's relationship with other methodolo-
  gies.  Technicalities such as Obsoletes, Provides, Requires, Buil-
  dRequires, %setup, and other RPM Specification file details may also
  be addressed.
  ______________________________________________________________________

  Table of Contents


  1. Existing Conventions
     1.1 Fedora
     1.2 ATrpms
     1.3 PyPackage.org
     1.4 Dag

  2. Naming Standard
     2.1 Goal
     2.2 Configuration
     2.3 Suffix Scheme
     2.4 Library Add-ons
     2.5 Applications


  ______________________________________________________________________

  1.  Existing Conventions

  1.1.  Fedora

  See http://www.fedora.us/wiki/PackageNamingGuidelines. There is a long
  explanation about vepochs, which I have doubts they are absolutely
  necessary for every package, so I'll take this on an as-needed basis.


  1.2.  ATrpms

  ATrpms uses a more Redhat-esque approach by naming every package,
  regardless of its role, closer to the original package name as
  distributed by the original Python package.


  1.3.  PyPackage.org

  Packages found at pypackage.org are all written in lowercase with a
  few exceptions. The convention of prefixing "python" is also used for
  add-on libraries.


  1.4.  Dag

  The dag repository uses a similar convention as pypackage.org.


  2.  Naming Standard

  2.1.  Goal

  The goal of the PyVault repository is to provide the latest in Python
  on a wide range of RPM platforms including those that already contain
  and depend upon an older copy of Python. PyVault packages are created
  with the intent of being a packaged sub-system only repackaging the
  absolute minimal necessary dependencies.


  Distribution releases never correspond with major releases of Python;
  it wouldn't be possible to enact such coordination. Therefore, PyVault
  will track the latest versions of Python and major third-party
  libraries.


  A typical use for the repository would be:



  1. Develop programs in a Fedora Core 2 environment, using
     bicyclerepair, scons, and other development tools.

  2. Program is deployed into a cluster running Redhat 7.3 or Redhat 9.
     As the cluster is running in a 24-hour non-stop environment, only
     user-level package modifications can be made. (Obviously, after
     some testing...)

  PyVault will not create a slew of compatibility packages nor will it
  attempt to upgrade distribution-specific packages that depend on an
  existing version of Python. The Vault exists in its own litle corner.


  2.2.  Configuration

  PyVault will depend on configuration found in the build user's
  ~/.rpmmacros file to determine what suffix to use on a repository-wide
  basis. This will lessen the need for re-editing all the spec files
  when the next version of Python is released.


  Typical configuration (XXX - sorry for the LyX/linuxdoc bug and I
  can't get sgml/docbook from atrpms working):



  ______________________________________________________________________
  <![CDATA[%packager       PyVault Repository <http://pyvault.berlios.de/>
  ]]><![CDATA[%vendor         PyVault
  ]]><![CDATA[%pyver          2.3
  ]]><![CDATA[%pypatch_level  2.3.3
  ]]><![CDATA[%python         python%{pyver}
  ]]><![CDATA[%__python       /usr/bin/python%{pyver}
  ]]><![CDATA[%pyusesuffix    1
  ]]>
  ______________________________________________________________________



  2.3.  Suffix Scheme

  With an older version of the Python binary on some RPM-based
  distributions, it is necessary to create a suffix scheme such that
  file conflicts are eliminated. In the default Python spec file, a
  macro named %{binsuffix} is used to concatenate against man pages and
  binaries found in /usr/bin.


  2.4.  Library Add-ons

  Add-on packages are those that are meant to be used from a user's
  Python program. A distinct attribute of a Python add-on package is
  over 80% of the installed files are located in the directory,
  /usr/lib/python?.?/site-packages/. These packages will be named with a
  prefix to the tune of how Perl Add-on libraries are named:



  +o  python-crypto

  +o  python-soappy

  +o  python-twisted

  XXX - Do we want all lowercase, or bumpy text matching original
  package name?


  XXX - Do we want to simplify package naming? PyXML --> python-xml,
  PyOpenSSL -> python-openssl?


  2.5.  Applications

  Third-party applications will follow regular package naming
  conventions.  The following are a few examples:



  +o  zope

  +o  scons

  XXX - Upper or lower case?