Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-council
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-council@g.o
From: Thomas Anderson <gentoofan23@g.o>
Subject: Comparison of GLEP 54 and 'live ebuild' proposal
Date: Mon, 9 Mar 2009 18:47:25 -0400

    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.

Thomas Anderson
Gentoo Developer
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
    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_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
    	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/
     in package.{use,keywords}? Is live expanded that early so it is invalid
     or is it still valid?
Re: Comparison of GLEP 54 and 'live ebuild' proposal
-- Luca Barbato
Re: Comparison of GLEP 54 and 'live ebuild' proposal
-- Roy Bamford
Lists: gentoo-council: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Reminder for Thursday's meeting
Next by thread:
Re: Comparison of GLEP 54 and 'live ebuild' proposal
Previous by date:
Re: GLEP 54/55 updates [WAS] Council Meeting summary for 26 February 2009
Next by date:
Re: Comparison of GLEP 54 and 'live ebuild' proposal

Updated Jun 17, 2009

Summary: Archive of the gentoo-council mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.