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.
Because this GLEP is dependent upon GLEP 55, which was not accepted by the council, we believe that the current proposal can not be implemented. We would respectfully request that a new GLEP is filed for this matter.
