William Hubbs posted on Fri, 05 Jun 2015 14:12:51 -0500 as excerpted:

> On Fri, Jun 05, 2015 at 09:34:42AM -0500, William Hubbs wrote:
>> On Fri, Jun 05, 2015 at 12:54:45AM -0400, Mike Frysinger wrote:
>>> On 04 Jun 2015 14:10, William Hubbs wrote:
>>>> # @DESCRIPTION:
>>>> # This eclass is written to ease the maintenance of live ebuilds
>>>> # of software written in the Go programming language.
>>> 
>>> this should note the ebuild is responsible for depending on the right
>>> vcs packages.  e.g. if you use git, then you need to depend on git.
>> 
>> Since "go get" fetches $EGO_PN and its dependencies, there is no way an
>> ebuild author could get this right without reading all of the import
>> statements in the source for their package and all of its dependencies.
>> I don't really want to ask ebuild authors to keep up with all of that.

>> I'm seeing two options. I can either let users emerge the vcs's they
>> need if something breaks or pull in all vcs's go supports.
>> 
>> Which way is best?
> 
> The more I think about this, I don't want to DEPEND on any vcs's and it
> is not reasonable to ask developers to do so in their go vcs ebuilds for
> the reason I stated above.
> 
> Since these are live ebuilds, I think we can assume more about the users
> that use them and not require the vcs's as runtime dependencies.

The way layman, for example, handles this is with USE flags for the 
various VCSs, and a post_inst message about what may not be supported due 
to missing VCSs.  But that won't work here, as it'd add all sorts of 
unrelated VCS flags to anything inheriting the eclass.

Maybe a USE_EXPAND variable?  That should be a bit better as it'd at 
least group the flags and make it more obvious what they're for and that 
not all may apply to every package.

Like many USE_EXPANDs, behavior could be default to them all if the 
USE_EXPAND isn't set, but the user can set it specifically to only what 
they know is needed, if they prefer.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


Reply via email to