diff options
Diffstat (limited to 'decisions/documents.tex')
-rw-r--r-- | decisions/documents.tex | 188 |
1 files changed, 188 insertions, 0 deletions
diff --git a/decisions/documents.tex b/decisions/documents.tex index b35d975..cc8301b 100644 --- a/decisions/documents.tex +++ b/decisions/documents.tex @@ -226,3 +226,191 @@ rest of the team to forward on for council approval. \chapter{Stabilization} + +\chapter{PMS, EAPIs, GLEPs, and similar} + +\section{Live Ebuild as template proposal} +\label{2000-02-luzero-live} +Source: \url{http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst}, file is dated +11 March 2009 +\index{GLEP!54} +\index{developer!lu_zero} +\vspace*{1cm} + +{\small \begin{verbatim} +:GLEP: XXX +:Title: Live Ebuild as Template +:Version: $Revision: $ +:Last-Modified: $Date: $ +:Author: Luca Barbato <lu_zero@gentoo.org>, +:Status: Draft +:Type: Standards Track +:Content-Type: text/x-rst +:Created: 12 Jun 2008 + +Credits +======= + +Thanks to Gianni Ceccarelli for the early feedback and markup help, Zack Medico +for pointing some issues and suggesting solutions (and pushing me to complete +it), Thomas Anderson for the help. + +Abstract +======== + +This glep provides a mechanism to allow traceable installation from +live source repositories (e.g. ``svn``, ``bzr``, ``git``) using +ebuilds. + +Motivation +========== + +Sometimes upstream may not provide releases often enough to satisfy certain +needs, either because there isn't a release schedule or the scheduled release +is too far to address certain issues or provide certain features in a timely +manner. + +In order to provide such fixes or features the main solutions had been either +backport them in form of patches or provide snapshots from the development +tree if the number of changes is too high. + +Sometimes is needed to update the snapshots often enough that would be simpler +directly using the live sources. + +Current situation (``-9999 ebuilds``) +----------------------------------- + +Right now the are some eclasses that on unpack phase fetch the sources from +the upstream server, prepare them and then the usual ebuild process follows. + +In order to make an ebuild using those eclasses be valued as the highest +possible, the simplest solution had been give it a version "high enough", +commonly ``9999``. +That makes simple track a single live branch per package. + +The same reasoning could be done with any version component in order to try +to track different branches: +- to track what will be the next ``1.5`` version, a version like ``1.4.9999`` + or 1.5_pre9999 could be used. +- to track all the improvements happening on the 1.5 branch somebody could use + a version like 1.5_p9999 or 1.5.9999 again. + +9999 is just an arbitrary big number. + +Shortcomings +------------ + +There are many obvious and non obvious shortcomings in this situations: +- you have to hand produce "high enough" version values and be sure they do + not clash (e.g. 2.3_pre9999 live ebuild being shadowed by 2.3_pre20050201 + snapshot). +- you cannot track what did you install since you don't have a precise + information about it, emerge logs will just provide you the build date. +- you cannot do exact reemerges and that may break revdep-rebuild +- the package manager isn't aware of the "liveness" condition. +- in order to refresh/update the installed package automatically you need + either to rely on script or on sets hand produced or heuristically defined + (e.g "all ebuilds that inherit eclass svn go in svn set"). +- since you fetch on unpack phase you cannot use emerge --fetch consistently. + + +This document aims to address the above shortcomings. + +Use Cases +========= + +Those are the following use case considered:: + + * track the tip of the main branch + * track specific version branches + * track multiple topic branches + * + + +Backwards Compatibility +======================= + +This is an expansion to [GLEP54]_. + + +Live Template +============= + +Structure +--------- + +Any numeric version component could be substituted with the keyword ``live``. +The keyword must be present at most one time:: + + ``cat/pkg-live`` + ``cat/pkg-1.live`` + ``cat/pkg-1.2.live`` + ``cat/pkg-1.2.3_prelive`` + ``cat/pkg-1.2.2_plive`` + +It's advised not to chain suffixes beside ``-r`` after the live keyword +even if is possible (e.g. ``cat/pkg-1.2.live_pre``) + +Resolution and Version Comparison +--------------------------------- + +At resolution the live keyword is substituted with a timestamp in the form of +iso date (``YYYYMMDDhhmm``) and the version comparison follows the normal +version comparison rules. + +Generation +---------- + +[Details about generating a normal ebuild out of template] + +Informations shown on pretend +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The live template is always resolved to a snapshot value, portage should mark +both template and rendered templates to notify the user. + +live template yet to be rendered could get a specific letter "L" in order to +mark it or it could be shown as is. +Rendered templates will shown with the version with ``live`` replaced with the +iso date and the informations about the branch and revision name will be shown +on verbose in a fashion similar to what is used for useflags. + +Additional Phase +~~~~~~~~~~~~~~~~ + +[Reference about ``src_fetch`` bugXXXX_] + +Revision information embedding +------------------------------ + +In order to properly allow re-emerge, it's required that additional informations +will be stored and exposed to portage. + +Eclass Support +~~~~~~~~~~~~~~ + +Live templates will use a standardized form of eclass interface to expose the +revision information to the ebuild and the package manager. + +Every ebuild will expose the following variables: + +``LIVE_URI`` +``LIVE_BRANCH`` +``LIVE_REVISION`` + + +References +========== + +.. [GLEP54] scm package version suffix + (http://glep.gentoo.org/glep-0054.html) +.. [bugXXXX] src_fetch rfe (http://bugs.gentoo.org/XXXX) + + + +Copyright +========= + +This document has been placed in the public domain. + +\end{verbatim}} |