[gentoo-council] Comparison of GLEP 54 and 'live ebuild' proposal

[Thomas Anderson <gentoofan23@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 328 bytes --]

Hi,

    Attached is my comparison of the two proposals for live sources.
    Sorry about getting it out late, I had to get ahold of a number of
    people to finish writing it up.

Cheers,
Thomas
-- 
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------

[-- Attachment #2: glep54comp.txt --]
[-- Type: text/plain, Size: 2847 bytes --]

GLEP54:
    This proposal attempts to have proper ordering with all version 
    parts(0.2-scm should be higher than 0-2.1) while providing information to
    the package manager and user that this package should be treated like an
    ebuild with live sources. This proposal has the added advantage that it's
    already supported in at least one package manager so it's behaviour is
    defined and predictable.

    The only real objection to this proposal is that some don't like the
    version component name('scm'). No technical objections have been made,
    other than that it "doesn't go far enough".

    One thing immediately found lacking in this proposal is the lack of time
    of installation or the revision used. As stated in the GLEP however, this
    information can be exposed in other ways by the underlying scm tool. The
    specific revision however should not be in the package version but
    otherwise available.

Live Ebuild:
    The liveebuild proposal attempts to give both proper ordering and an idea
    of point of time when the ebuild was installed, in other words,
    'traceability' of live package. A keyword 'live' in the
    package version part of the filename is expanded to the ISO
    date(YYYYMMDD). One difference with GLEP54 is that while package managers
    supporting GLEP54 can on that information alone determine if a package is
    a live-sources package, with the live ebuild method one needs
    PROPERTIES=live as well(once the version is expanded one cannot know if it
    was a normal ebuild or a .live ebuild).

    A problem with liveebuild is that there has been no real specification
    other than the outline provided. A consequence is that there has not been
    consideration of what happens when you have two ebuilds:
    	mythtv-0.20_prelive
	mythtv-0.20_pre20090309(today's date, which live would expand to)
    I've not seen any discussion or explanation of what would happen. This
    probably needs to be sorted out before this proposal can be accepted.
    This cannot be easily solved by saying "No two ebuilds in the same package
    can have the same version components because we never know what _live will
    expand to.

    One important issue is what happens in the following
    scenario:
    	1) world update starts at 20090301@2200hrs.
	2) this particular update involves 100 packages so it takes quite
	along time
	3) The _live package is not reached until 20090302 at 1AM.

     Is the package installed as 20090301 or 20090302?

     Similar to the above problem is what occurs when a user understandably
     puts =media-tv/mythtv-0.20_20090301 in package.{use,keywords} and the
     date changes. Also, what happens if the user =media-tv/mythtv-0.20.live
     in package.{use,keywords}? Is live expanded that early so it is invalid
     or is it still valid?