234711 2008-08-14 08:53 0000 GLEP 54: scm package version suffix 2009-06-01 07:19:18 0000 1 1 1 Unclassified Gentoo Linux Unspecified unspecified All Linux NEW P2 normal --- 1 dberkholz@gentoo.org lu_zero@gentoo.org arfrever@gentoo.org coldwind@gentoo.org council@gentoo.org levertond@googlemail.com oahong@gmail.com pacho@condmat1.ciencias.uniovi.es peper@gentoo.org zmedico@gentoo.org dberkholz@gentoo.org 2008-08-14 08:53:54 0000 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. cardoe@gentoo.org 2008-10-21 20:59:12 0000 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. cardoe@gentoo.org 2008-11-13 20:16:39 0000 Does anybody have anything to report here? I know Portage is getting support for live sets. How does that play with this ticket? lu_zero@gentoo.org 2008-11-13 20:25:57 0000 I put my alternate proposal on hold since the autogenerated set for live ebuilds is a good solution about tracking them. dberkholz@gentoo.org 2008-11-13 21:27:31 0000 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. zmedico@gentoo.org 2008-11-20 20:20:00 0000 (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. lu_zero@gentoo.org 2009-02-12 22:54:41 0000 (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.