Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: new eclass: go-live.eclass for handling go live ebuilds
Date: Sat, 06 Jun 2015 06:45:43
Message-Id: pan$5c2b5$4de8d6a3$7e97a5e8$78a33537@cox.net
In Reply to: Re: [gentoo-dev] new eclass: go-live.eclass for handling go live ebuilds by William Hubbs
1 William Hubbs posted on Fri, 05 Jun 2015 14:12:51 -0500 as excerpted:
2
3 > On Fri, Jun 05, 2015 at 09:34:42AM -0500, William Hubbs wrote:
4 >> On Fri, Jun 05, 2015 at 12:54:45AM -0400, Mike Frysinger wrote:
5 >>> On 04 Jun 2015 14:10, William Hubbs wrote:
6 >>>> # @DESCRIPTION:
7 >>>> # This eclass is written to ease the maintenance of live ebuilds
8 >>>> # of software written in the Go programming language.
9 >>>
10 >>> this should note the ebuild is responsible for depending on the right
11 >>> vcs packages. e.g. if you use git, then you need to depend on git.
12 >>
13 >> Since "go get" fetches $EGO_PN and its dependencies, there is no way an
14 >> ebuild author could get this right without reading all of the import
15 >> statements in the source for their package and all of its dependencies.
16 >> I don't really want to ask ebuild authors to keep up with all of that.
17
18 >> I'm seeing two options. I can either let users emerge the vcs's they
19 >> need if something breaks or pull in all vcs's go supports.
20 >>
21 >> Which way is best?
22 >
23 > The more I think about this, I don't want to DEPEND on any vcs's and it
24 > is not reasonable to ask developers to do so in their go vcs ebuilds for
25 > the reason I stated above.
26 >
27 > Since these are live ebuilds, I think we can assume more about the users
28 > that use them and not require the vcs's as runtime dependencies.
29
30 The way layman, for example, handles this is with USE flags for the
31 various VCSs, and a post_inst message about what may not be supported due
32 to missing VCSs. But that won't work here, as it'd add all sorts of
33 unrelated VCS flags to anything inheriting the eclass.
34
35 Maybe a USE_EXPAND variable? That should be a bit better as it'd at
36 least group the flags and make it more obvious what they're for and that
37 not all may apply to every package.
38
39 Like many USE_EXPANDs, behavior could be default to them all if the
40 USE_EXPAND isn't set, but the user can set it specifically to only what
41 they know is needed, if they prefer.
42
43 --
44 Duncan - List replies preferred. No HTML msgs.
45 "Every nonfree program has a lord, a master --
46 and if you use the program, he is your master." Richard Stallman