Summary: | GLEP 54: scm package version suffix | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Donnie Berkholz (RETIRED) <dberkholz> |
Component: | [OLD] Unspecified | Assignee: | Luca Barbato <lu_zero> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | CC: | arfrever, coldwind, council, levertond, oahong, pacho, peper, zmedico |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Donnie Berkholz (RETIRED)
2008-08-14 08:53:54 UTC
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. |