public inbox for gentoo-pms@lists.gentoo.org
 help / color / mirror / Atom feed
From: Brian Harring <ferringb@gmail.com>
To: Micha?? G??rny <mgorny@gentoo.org>
Cc: gentoo-dev@lists.gentoo.org, gentoo-pms@lists.gentoo.org
Subject: [gentoo-pms] Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposas
Date: Tue, 18 Sep 2012 03:45:00 -0700	[thread overview]
Message-ID: <20120918104500.GE5384@localhost> (raw)
In-Reply-To: <20120918114742.7e87a411@pomiocik.lan>


On Tue, Sep 18, 2012 at 11:47:42AM +0200, Micha?? G??rny wrote:
> On Tue, 18 Sep 2012 02:24:26 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> 
> > On Tue, Sep 18, 2012 at 10:25:51AM +0200, Micha?? G??rny wrote:
> > > > test depends: to specifically mark those dependencies that are
> > > > only needed for when the pkg is being tested; effectively
> > > > ephemeral build/run time depends that go away once testing is
> > > > completed.
> > > 
> > > Does that mean that USE=test is going away somehow?
> > 
> > If you think it through, a test use flag still is needed in the cases 
> > where the rdep itself would change if test was enabled; such a source 
> > is fairy rare, but not always just someone being moronic- certain 
> > cases to do testing, the tests need to reach in fairly deeply and 
> > recompilation for compile vs test isn't exposed.
> 
> Yes, and sometimes we're doing 'use test'. I simply don't see how
> adding a separate group of dependencies just for 'test' phase is going
> to help us.
> They fit just fine into build-time dependencies right now.

I'm going to assume you  typo'd "build-time" into "run-time"; on the 
offchance you've never written actual test code, to test the code you 
have to *run* the results.

Simple example, portage doesn't need eselect nor logrotate, nor afaik 
selinux or paxutils, till runtime since it doesn't test those 
pathways.

A non-crap resolver can exploit that gap when it comes to 
parallelization.

Just heading off an email from you, no, you cannot just stick it into 
RDEPEND then.

If you did so, the test deps would be locked into the required runtime 
graph for as long as the pkg was installed.

If in doubt of how that matters; trace the usage of gtest, nose, etc.  
Nose is a good example additionally since a properly setup setup.py, 
the pkg doesn't need nose for build- just strictly for test.



> > > A quick
> > > glance shows that what you have expanded there, a fairly reasonable
> > > Gentoo dev will solve using:
> > >
> > > RDEPEND="[common depends]"
> > > DEPEND="${RDEPEND}
> > >     [build only depends]"
> > 
> > from diffball (under current EAPIs)
> > 
> > """
> > RDEPEND=">=sys-libs/zlib-1.1.4
> >         >=app-arch/bzip2-1.0.2
> >         app-arch/xz-utils"
> > DEPEND="${RDEPEND}
> >         virtual/pkgconfig"
> > """
> > 
> > becomes the following under the proposal:
> > 
> > """
> > DEPENDENCIES=">=sys-libs/zlib-1.1.4
> >         >=app-arch/bzip2-1.0.2
> >         app-arch/xz-utils"
> >         dep:build? ( virtual/pkgconfig )"
> > """
> 
> Err, shouldn't the first three deps be namespaced?

No.

Please read the glep, specifically the section "basic rules".


Also, you come up with a valid criticism, valid point, etc, something 
*worthwhile*, I'll respond.  If it doesn't meet that criteria, assume 
I won't respond (feel free to bitch to the council during whatever 
vote occurs for this GLEP that I ignored your noise; it's a risk I'll 
willingly take).

~harring


  reply	other threads:[~2012-09-18 10:45 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-16 13:52 [gentoo-pms] GLEP: gentoo sync based unified deps proposal Brian Harring
2012-09-16 14:39 ` Ciaran McCreesh
2012-09-16 16:05   ` Brian Harring
2012-09-16 16:59     ` Ciaran McCreesh
2012-09-25 22:46       ` Brian Harring
2012-09-29 16:05         ` Ciaran McCreesh
2012-09-30 20:14           ` Brian Harring
2012-09-30 20:30             ` Ciaran McCreesh
2012-09-30 21:42               ` Brian Harring
2012-09-30 21:53                 ` Ciaran McCreesh
2012-09-30 23:56                   ` Brian Harring
2012-10-01  7:13                     ` Ciaran McCreesh
2012-10-01  9:01                       ` Brian Harring
2012-10-01  9:15                         ` Ciaran McCreesh
     [not found] ` <CAMUzOag1GDyJYRZTDa6zfEgJfqM22mFZ+A9X+ka=HeUA-zq1Hg@mail.gmail.com>
2012-09-17  3:08   ` [gentoo-pms] Re: [gentoo-dev] " Brian Harring
2012-09-18  8:25 ` Michał Górny
2012-09-18  9:24   ` Brian Harring
2012-09-18  9:47     ` Michał Górny
2012-09-18 10:45       ` Brian Harring [this message]
2012-09-26  6:58 ` Michał Górny
2012-09-26 10:33   ` Brian Harring
2012-09-28 12:17   ` Brian Harring

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120918104500.GE5384@localhost \
    --to=ferringb@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=gentoo-pms@lists.gentoo.org \
    --cc=mgorny@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox