Bugzilla Bug 234711

Open questions:

<Betelgeuse@> dberkholz: with GLEP 55 EAPI X can add the support for scm
<Betelgeuse@> dberkholz: and older Portage versions work just fine

<Betelgeuse@> dberkholz: In general I oppose adding things to EAPI 0

<   lu_zero@> dberkholz problem: if you have -scm installed
<   lu_zero@> and then switch to a pm not knowing it
<   lu_zero@> you have a nice recipe for inconsistency

<   Halcy0n@> I would really like to see a list of features that we would 
                    end up having after implementing this GLEP.  The GLEP 
                    mentions possible enhancements, but I'd like to see what we 
                    would have planned if we go forward with this change.
<   Halcy0n@> Well, it only mentions one enhancement, I'd like to see 
                    what else we could do to judge if it is worth it.
Halcy0n@> Betelgeuse: yes, I know there are some things we could do,
                    but I'd like to see a more extensive list of possibilities, 
                    what are other possible ways of doing this (like a metadata 
                    tag for the ebuild), and why those other methods aren't 
                    sufficient.

< dberkholz@> i think the point here is that the glep should address what 
                    made its implementation superior to other possible ones, 
                    which it also describes

< dberkholz@> ok, i've noted the issues raised here
< dberkholz@> once they're address, the glep can be revised and we'll 
                    consider it again

Summary: Specific questions and requests are above.

I believe lu_zero had a counter proposal available at:
http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst but both of these seem to
have been dropped as a result of disagreement on the mailing lists.

Any chance we can have both sides re-present because this sounds like a clear
task for the council to vote on one or the other.

Does anybody have anything to report here? I know Portage is getting support
for live sets. How does that play with this ticket?

I put my alternate proposal on hold since the autogenerated set for live
ebuilds is a good solution about tracking them.

Summary of additional discussion:

- David Leverton said identifying packages in the set by using inherited
eclasses, as portage does, was hackish. (Portage info is at
<http://planet.gentoo.org/developers/zmedico/2008/07/31/live_rebuild_package_set>.)
- PROPERTIES=live is another option
<http://archives.gentoo.org/gentoo-dev/msg_64b83155637bcad67478e2d2af276780.xml>
- Updating only when the upstream code changes could be addressed in a future
EAPI by bug #182028.

(In reply to comment #1)
> I believe lu_zero had a counter proposal available at:
> http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst but both of these seem to
> have been dropped as a result of disagreement on the mailing lists.

It like this proposal, but I have a couple suggestions:

1) Replace .live suffix with _live, for consistency with existing version
suffixes.

2) Use an YYYYMMDDhhmm for the version autoincrement, so that it's universal
rather than being dependent on local factors.

3) Include some easy way to identify that the installed package was live
(assuming that the live suffix is replaced by the autoincrement), perhaps by
tagging it with PROPERTIES=live.

(In reply to comment #5)
> (In reply to comment #1)
> > I believe lu_zero had a counter proposal available at:
> > http://dev.gentoo.org/~lu_zero/glep/liveebuild.rst but both of these seem to
> > have been dropped as a result of disagreement on the mailing lists.
> 
> It like this proposal, but I have a couple suggestions:
> 
> 1) Replace .live suffix with _live, for consistency with existing version
> suffixes.

It should be used instead of _pre so makes sense

> 
> 2) Use an YYYYMMDDhhmm for the version autoincrement, so that it's universal
> rather than being dependent on local factors.

Ok

> 3) Include some easy way to identify that the installed package was live
> (assuming that the live suffix is replaced by the autoincrement), perhaps by
> tagging it with PROPERTIES=live.

PROPERTIES=live could be set by the eclass.