Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 234711 - GLEP 54: scm package version suffix
Summary: GLEP 54: scm package version suffix
Status: RESOLVED CANTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Luca Barbato
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-08-14 08:53 UTC by Donnie Berkholz (RETIRED)
Modified: 2011-09-13 19:31 UTC (History)
8 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Donnie Berkholz (RETIRED) gentoo-dev 2008-08-14 08:53:54 UTC
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.
Comment 1 Doug Goldstein (RETIRED) gentoo-dev 2008-10-21 20:59:12 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.
Comment 2 Doug Goldstein (RETIRED) gentoo-dev 2008-11-13 20:16:39 UTC
Does anybody have anything to report here? I know Portage is getting support for live sets. How does that play with this ticket?
Comment 3 Luca Barbato gentoo-dev 2008-11-13 20:25:57 UTC
I put my alternate proposal on hold since the autogenerated set for live ebuilds is a good solution about tracking them.
Comment 4 Donnie Berkholz (RETIRED) gentoo-dev 2008-11-13 21:27:31 UTC
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.
Comment 5 Zac Medico gentoo-dev 2008-11-20 20:20:00 UTC
(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.
Comment 6 Luca Barbato gentoo-dev 2009-02-12 22:54:41 UTC
(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.

Comment 7 Tony Vroon (RETIRED) gentoo-dev 2011-09-13 19:31:57 UTC
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.