[gentoo-dev] GLEP: gentoo sync based unified deps proposal

[gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

Folks-

Keeping it short and quick, a basic glep has been written for what I'm 
proposing for DEPENDENCIES enhancement.

The live version of the doc is available at 
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html 

Wording fixes will occur, but the core concept shouldn't change (and 
if it does, per PEP standards, the changes will be noted/tracked).

Please have a read through; it should be clear/concise as to why PM 
authors are pushing for a unified dependencies to be done, what we can 
get from it now, what it enables moving forward, and the direct cost 
to devs should this idea be implemented.

Just to be absolutely clear, what I'm proposing is basically zero cost 
for devs- they can (and should when it's in their benefit) switch to 
the new syntax when it makes their job easier; it can be used in 
parallel to existing DEPEND/RDEPEND/PDEPEND both to ease 
transition/compatibility.

In addition, a prototype portage patch has been cut for dependencies 
support (needs work/full validation), and a matching pkgcore one has 
been cut.

I realize it's a complex subject; if you have questions, please feel 
to ask.

Thanks, and pardon the ancillary/daft noise that has gone with this 
subject.

~harring

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2990 bytes --]

On Sun, 16 Sep 2012 06:52:11 -0700
Brian Harring <ferringb@gmail.com> wrote:
> The live version of the doc is available at 
> http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html 

I think you're being a bit glib with your dismissal of the labels
parsing scheme. You've got the following problems, that labels don't
have:

You dismiss the dep:build? ( dep:run? ( ) ) problem as "don't do that".
Labels doesn't have this problem: it doesn't try to reuse an existing
syntax precisely because the existing syntax is extremely awkward for
this kind of thing.

You say there's an implict "build,run". This can't be an implicit
"dep:build,run? ( )" using that syntax, however, since then you
wouldn't be able to put a dep:post? inside it by the above. So again
you've got a special case to deal with simply because of the syntax --
your syntax doesn't correspond directly to the meaning of dependencies.

There's also the issue of what negations do at the top level...

You discourage grouping of dependencies by the use flag that selects
them (see xscreensaver in your examples). Logically, "xscreensaver
related things" belong together. Your negation example also tries to
bring related dependencies together. But it's a mess. What if one of
the dependencies was a build dependency, and one a run dependency?
You'd end up with something silly like this:

    dep:build,run? (
        !dep:run? ( dev-util/diffball )
        !dep:build? ( dev-util/bsdiff )
    )

Your syntax also prevents the following:

    DEPENDENCIES="foo? ( $(make_foo_deps blah) )"

and would encourage something like this instead:

    DEPENDENCIES="
        dep:build? ( foo? ( $(make_foo_build_deps blah) ) )
        dep:run? ( foo? ( $(make_foo_run_deps blah) ) )
        dep:build,run? ( foo? ( $(make_foo_build_and_run_deps blah) ) )

which makes it much harder for the foo.eclass authors to switch what
kinds of dependencies they use. For example, if foo.eclass starts
needing an install dependency, your syntax requires every foo user to
be updated, whereas labels does not. To get around that, you'd have to
allow deeply embedded dep: blocks.

You're also still speaking in terms of "rendering DEPEND" etc. That's
not really what we want, though. As you've observed, a lot of atoms are
in both DEPEND and RDEPEND. Conceptually, it makes much more sense to
consider such an atom to be a single dependency that is both a build
and a runtime dependency than it does to consider it as two unrelated
dependencies. This is especially the case now that we have := slot
dependencies.

Ultimately, it comes down to the observation that the flag? ( ) syntax
is strongly nested and hierarchical, but dependency roles aren't.
Labels can give all the advantages of your proposal (including the
backwards compatibility, if that's desired), but without the need to
shoehorn the idea into an unsuitable syntax.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Sun, Sep 16, 2012 at 03:39:49PM +0100, Ciaran McCreesh wrote:
> On Sun, 16 Sep 2012 06:52:11 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > The live version of the doc is available at 
> > http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html 
> 
> I think you're being a bit glib with your dismissal of the labels
> parsing scheme. You've got the following problems, that labels don't
> have:
> 
> You dismiss the dep:build? ( dep:run? ( ) ) problem as "don't do that".

x? ( !x? ( dep ) ) already exists syntactically.  dep:build? ( 
dep:run? ( blah ) ) is no different, so yes, I dismiss it- frankly 
with prejudice since you keep bringing that example up but ignoring 
that it's not a new issue (plus ignoring that it never occurs in the 
wild because it's a self-solving issue).


> Labels doesn't have this problem: it doesn't try to reuse an existing
> syntax precisely because the existing syntax is extremely awkward for
> this kind of thing.

Labels have a human comprehension problem, and require a fair amount 
more work for the various parsers.

You may not agree on that view, but there seems to be some consensus 
on that (as much as one ever gets in gentoo at least).


> You say there's an implict "build,run". This can't be an implicit
> "dep:build,run? ( )" using that syntax, however, since then you
> wouldn't be able to put a dep:post? inside it by the above. 

You're misunderstanding; you're thinking about it as to how exheres 
labels are done which is basically
build+run: ${DEPENDENCIES}

One thing to keep in mind here; I don't mind making the parser do some 
extra work if it's easier on devs to deal with (including 
aesthetically; like it or not, dependencies is needed, and screaming 
"labels are the one true religion" isn't going to get us to where we 
need to go- pragmatic compromise will).

Either way, in the absense of an explicit dep context, dep:build,run? 
is assumed.  The parser/visitation implementation is admittedly more 
complex, but it's not in the realm of 'hard'.  This is assuming a 
non-shit implementation mind you.

Either way, my focus here is on the human, as I've stated.


> So again
> you've got a special case to deal with simply because of the syntax --
> your syntax doesn't correspond directly to the meaning of dependencies.

"doesn't correspond directly to the meaning of dependencies" is a 
vague assertion; back that one up.  I'm assuming you're complaining 
that conditionals are being used (the "but they're not USE flags!" bit 
which is a subjective view of the conditional namespace).

If that's not what you're referencing, then frankly I'll just go with 
"explain to me how this same critique doesn't apply to labels".


> There's also the issue of what negations do at the top level...

Yeah, I did skimp on that one; technically speaking, negations aren't 
required if they prove too much of a pain in the ass.  Negation at the 
top level could be interpretted two ways:

1) negating against all possible dep types; thus a !dep:build? would 
be dep:post,run? .  Too slick in my view, but who knows, othes may 
think it straight forward.

2) Treat it as a negation of the implicit dep:build,run; meaning 
!dep:build? would be dep:run?.

Unsure of which is preferably at this juncture.

> You discourage grouping of dependencies by the use flag that selects
> them (see xscreensaver in your examples). Logically, "xscreensaver
> related things" belong together.

I do not discourage grouping.  The example is an automated 
conversion, as explicitly mentioned in the doc.

A secondary condensing of those deps I'll add to make clear it's 
supported.


> Your negation example also tries to
> bring related dependencies together. But it's a mess. What if one of
> the dependencies was a build dependency, and one a run dependency?
> You'd end up with something silly like this:
> 
>     dep:build,run? (
>         !dep:run? ( dev-util/diffball )
>         !dep:build? ( dev-util/bsdiff )
>     )

Ciaran, we use a fucking bash format.  We lost the ability to block 
silly idiocy long ago via that choice.

As said, 'x? ( !x? ( dep ) )' already exists, despite being dumb.  The 
beauty of it however is that the syntax rules themselves make it such 
that it doesn't ever actually come up in real world usage- the dep 
wouldn't be used fundamentally.

My intention is a syntax/format that is natural to the dev, and 
doesn't force them to do silly shit.  If they choose to do silly shit, 
that's on their head; trying to explicitly ban all possible dumb uses 
just makes the rules worse via increased complexity.

Also, just to be clear, this critique applies to exheres labels just 
the same. That example, rewritten to drop the negations is thus:

dep:build,run? ( 
  dep:build? ( dev-util/diffball )
  dep:run? ( dev-util/bsdiff )
)

Yep.  That's pretty dumb.  But no less retarded than someone doing the 
following in labels:

build+run:
  build: dev-util/diffball
  run: dev-util/bsdiff

Which I'll note isn't banned in your usage, despite the idiocy of such 
a construct.



> Your syntax also prevents the following:
> 
>     DEPENDENCIES="foo? ( $(make_foo_deps blah) )"

Err, no it doesn't.  I think you're reading too literally into the 
example mplayer translation I put in the doc- again, that was just a 
quicky, automated form, you can push dep:blah down beneath 
conditionals as necessary/desired.

If you see something claiming otherwise, or implying otherwise in the 
glep, please tell me exactly where so I can fix the wording.

> 
> and would encourage something like this instead:
> 
>     DEPENDENCIES="
>         dep:build? ( foo? ( $(make_foo_build_deps blah) ) )
>         dep:run? ( foo? ( $(make_foo_run_deps blah) ) )
>         dep:build,run? ( foo? ( $(make_foo_build_and_run_deps blah) ) )
> 
> which makes it much harder for the foo.eclass authors to switch what
> kinds of dependencies they use. For example, if foo.eclass starts
> needing an install dependency, your syntax requires every foo user to
> be updated, whereas labels does not. To get around that, you'd have to
> allow deeply embedded dep: blocks.

This critique is based on the same misunderstanding, just to be clear.


> You're also still speaking in terms of "rendering DEPEND" etc.

Babysteps.  First switch the internals to DEPENDENCIES, render from 
that to *DEPEND; in doing so, it's minimally disruptive for the PM, 
and for devs.

> That's
> not really what we want, though. As you've observed, a lot of atoms are
> in both DEPEND and RDEPEND. Conceptually, it makes much more sense to
> consider such an atom to be a single dependency that is both a build
> and a runtime dependency than it does to consider it as two unrelated
> dependencies. This is especially the case now that we have := slot
> dependencies.

Agreed, but we're not going to get to where we want without going 
through transition phases; at the PM level, minimally these 
enhancements:

1) first, collapse dependencies down, than render the *DEPEND views,
  thus enabling easy and quick initial integration; effectively
  no impact on the api/functionality of the PM at this phase.
2) Start converting the internals of the PM over such that it 
  operates, directly from that parsed tree, rathrer having to
  operate on a flatten/reduced/rendered version of it for each 
  context.
3) Once that's in place, start teaching the resolver how to make 
  better decisions via the better dependency groupping.

That's the rough roadmap for PM's were this to be added, exempting 
integration of any new dependency types.

For devs, they're not going to migrated at the flip of a switch.  Thus 
the same general transition approach;

1) switch the focus to DEPENDENCIES via collapsing 
  depend/rdepend/pdepend into it.  This allows existing code to work 
  in EAPI5 (or whichever this lands in).
2) New dependency forms should be added to DEPENDENCIES only; this is
  a bit of a carrot to get folks to migrate.
3) As ebuilds/eclasses get further along, and <EAPI5 support gets
  increasingly dropped, devs are encouraged (and hopefully willing
  since the syntax should make their lives easier) to migrate to the
  new form.
4) Some point down the line when we've neared an appropriate critical 
  mass, we discontinue the no longer necessary *DEPEND appending into
  DEPENDENCIES; basically deprecate and/then ban *DEPEND in the EAPI 
  of that day.  *DEPEND fades into the dust, same as how implicit 
  RDEPEND=${RDEPEND-${DEPEND}} was phased out.


> Ultimately, it comes down to the observation that the flag? ( ) syntax
> is strongly nested and hierarchical, but dependency roles aren't.

There is a bit of truth in that views on flag? ( ) vs the random-ass 
context labeling (which is hierarchical- keep in mind your stack 
pushing/popping confusion).

That said, just because it *is*, doesn't mean it has to get in the 
way.  Devs are already quite familiar w/ the hierarchical/nesting 
behaviour of flag? ( ); I seriously doubt they are going to have 
problems making dep:* work.

Basically, yes, there are some limitations; do they matter?  Not 
really, no.

Is it a perfect scheme?  While a neat reuse of existing syntax, no, 
it's not perfect.

But it's realistic, and *doable*.  That counts for a fucking helluva 
lot more than chasing the perfect solution.

I expect you'll inject some rant, but frankly REQUIRED_USE is a good 
example of what I'm talking about; the synax sucks, it's a bit 
painful, but it filled a needed gap and got the job done- 10% of EAPI4 
ebuild are using it after all (please skip the required-use rant also, 
whatever the flaws, one cannot argue w/ the usage).


> Labels can give all the advantages of your proposal (including the
> backwards compatibility, if that's desired), but without the need to
> shoehorn the idea into an unsuitable syntax.

If you want your proposal to go anywhere, you're going to need a 
better transition plan then "and.... then devs convert their 
ebuilds/eclasses".  I'd suggested it prior, but no traction there.

Either way, you push your syntax, I'll push mine; I'm fine w/ devs 
choosing the one that best fits their flow.

~harring

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3732 bytes --]

On Sun, 16 Sep 2012 09:05:28 -0700
Brian Harring <ferringb@gmail.com> wrote:
> > Labels doesn't have this problem: it doesn't try to reuse an
> > existing syntax precisely because the existing syntax is extremely
> > awkward for this kind of thing.
> 
> Labels have a human comprehension problem, and require a fair amount 
> more work for the various parsers.
> 
> You may not agree on that view, but there seems to be some consensus 
> on that (as much as one ever gets in gentoo at least).

I've never heard that view coming from anyone who has actually used
labels. It's only come from people who haven't tried using it, and who
have a history of disagreeing with anything that says 'Exherbo' on it.
You're taking about consensus among people who have never tried it
because they don't like it; consensus among people who have tried it is
that the labels syntax is good.

> My intention is a syntax/format that is natural to the dev, and 
> doesn't force them to do silly shit.

Labels already solve that. We know because we've got extensive
experience with them. Adoption of labels has been demonstrated to be
easy, both for former Gentoo developers and for people who haven't
previously written ebuilds.

We *know* that labels are easy to learn and easy to use. We also know
that they admit an efficient implementation, that they compose nicely,
that they allow dependencies to be specified accurately and that they
scale to larger numbers of dependency classes.

> > Your syntax also prevents the following:
> > 
> >     DEPENDENCIES="foo? ( $(make_foo_deps blah) )"
> 
> Err, no it doesn't.  I think you're reading too literally into the 
> example mplayer translation I put in the doc- again, that was just a 
> quicky, automated form, you can push dep:blah down beneath 
> conditionals as necessary/desired.
> 
> If you see something claiming otherwise, or implying otherwise in the 
> glep, please tell me exactly where so I can fix the wording.

The point is that nesting prevents composition. Labels are context
insensitive, which allows groups of dependencies to be added anywhere,
whereas dep: blocks can only be added if the surrounding groups are
specified in a particular way.

> 1) first, collapse dependencies down, than render the *DEPEND views,
>   thus enabling easy and quick initial integration; effectively
>   no impact on the api/functionality of the PM at this phase.

Specification in terms of rendering has a huge problem, though.
Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what does
this do?

    || ( dep:build? ( a ) dep:run? ( b ) )

> > Ultimately, it comes down to the observation that the flag? ( )
> > syntax is strongly nested and hierarchical, but dependency roles
> > aren't.
> 
> There is a bit of truth in that views on flag? ( ) vs the random-ass 
> context labeling (which is hierarchical- keep in mind your stack 
> pushing/popping confusion).

There's not any stack confusion in practice. Labels only have slightly
complicated rules to allow every side case to be covered. You're taking
the "don't do that" approach to nesting weirdness; labels go the
"specify it precisely" route instead.

> > Labels can give all the advantages of your proposal (including the
> > backwards compatibility, if that's desired), but without the need to
> > shoehorn the idea into an unsuitable syntax.
> 
> If you want your proposal to go anywhere, you're going to need a 
> better transition plan then "and.... then devs convert their 
> ebuilds/eclasses".  I'd suggested it prior, but no traction there.

Your "rewrite *DEPEND" approach can just as easily be used with labels.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

Pardon the delay; got busy with work, plus to actually address your
claims re: labels (or refute, as I intend to do)... data was 
necessary.

So I went and got the data. :)

Analysis was done roughly 09/17 or so; just looping back and 
commenting now however.


On Sun, Sep 16, 2012 at 05:59:21PM +0100, Ciaran McCreesh wrote:
> > > Your syntax also prevents the following:
> > > 
> > >     DEPENDENCIES="foo? ( $(make_foo_deps blah) )"
> > 
> > Err, no it doesn't.  I think you're reading too literally into the 
> > example mplayer translation I put in the doc- again, that was just a 
> > quicky, automated form, you can push dep:blah down beneath 
> > conditionals as necessary/desired.
> > 
> > If you see something claiming otherwise, or implying otherwise in the 
> > glep, please tell me exactly where so I can fix the wording.
> 
> The point is that nesting prevents composition. Labels are context
> insensitive, which allows groups of dependencies to be added anywhere,
> whereas dep: blocks can only be added if the surrounding groups are
> specified in a particular way.

Fun fact; peoples usage of labels in exherbo is thus:

build+run:
  set of deps
run:
  set of deps/conditionals/etc

You get the idea.  Technically, each block is usually wrapped in 
()... which frankly is a sign that the context switch third party 
code can introduce is problematic.  Basically, y'all are 
already using labels in exactly the fashion I propose, just 
with different synax.

I couldn't find a *single* instance of the following in usage in any git.exherbo repo:

build+run:
  dep1
  x? ( 
    dep2
    test:
      dep3
  )

Ie, a nested override.

Exherbo deps themselves basically dispute the claim that nesting 
somehow blocks people from doing composition; fact is, y'all can do 
nesting/context switching of a label w/in a block, but y'all don't at 
all.  This strongly makes me think you're either blowing smoke up 
folks asses or that you're chasing perfection ignoring the realities 
of how this is used on the ground.

Now, if there are actually examples of it in use in y'alls trees- 
(ones that aren't added after I send this email mind you ;) ) please 
point them out.  Offhand, there's actually 4 pkgs that do 
stacking/nesting of deps, although it's accidental and doesn't 
actually do it for gain.  They are:

dev-haskell/language-c[=0.3.2]::haskell
dev-haskell/language-javascript[=0.5.2]::haskell
kde/kdemultimedia[~scm]::kde
kde/kdemultimedia[=4.8.5]::kde

basically
DEPENDENCIES="
  ( build: some deps
    # dev forgot to close the block
    $(some dep_generator that forces a label immediately, per the norm)
  )"

While the norm is
DEPENDENCIES="
  ( build: some deps )
  ( $(some dep_generator that forces a label immediately) )"

Interesting sidenote btw; every usage I've found is directly 
translatable to my proposal, w/out any loss of expression in use.

Now, it's possible I fucked up.  I strongly doubt it however.  Please 
provide examples either way- else y'alls own dependencies disprove 
your claims about nesting being evil.

Either way, the data for that is at 
http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt


> > 1) first, collapse dependencies down, than render the *DEPEND views,
> >   thus enabling easy and quick initial integration; effectively
> >   no impact on the api/functionality of the PM at this phase.
> 
> Specification in terms of rendering has a huge problem, though.
> Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what does
> this do?
> 
>     || ( dep:build? ( a ) dep:run? ( b ) )

Honestly, I was waiting for you to bring this up :)

You're conflating two different things here;
1) someone being a dumb ass and writing what's effectively a || ( 
atom) block, just doing so in a manner w/out any reason to do so.

2) Your ongoing jihad against || (), specifically the occasionally 
valid complaint that build/rdepend different means the resolver can 
get stuck in certain pathways when slots are involved, abi, etc.

Either way, in my proposal, I'm not going to single that out and try 
blocking it.  The rendered version of it is still stable, albeit if 
it's build/run it's unlikely to be desired if there is ABI involved 
(for non ABI, specifically self-bootstrapping codebases, I suspect 
someone could come up with a valid construct- sed has something 
similar if memory serves).

Worth noting, the following idiocy is valid:

x? ( dev-util/diffball )
!dev-util/diffball

Which is stupid, but syntactically correct.  Nor is this a new issue, 
thus I don't particularly agree with your approach of trying to sink 
the proposal via an orthogonal problem.

This is why we have QA tools.
 

> > > Ultimately, it comes down to the observation that the flag? ( )
> > > syntax is strongly nested and hierarchical, but dependency roles
> > > aren't.
> > 
> > There is a bit of truth in that views on flag? ( ) vs the random-ass 
> > context labeling (which is hierarchical- keep in mind your stack 
> > pushing/popping confusion).
> 
> There's not any stack confusion in practice. Labels only have slightly
> complicated rules to allow every side case to be covered. You're taking
> the "don't do that" approach to nesting weirdness; labels go the
> "specify it precisely" route instead.

In practice, all usages explicitly go out of their way to protect 
themselves from the invoking context, and they use labels *exactly the 
same way as dep:build,run? ( blah )* would be used.

Basically the only real world benefit I've seen of labels vs what I've 
proposed is a *slight* collapsing of the tree- although that is more 
than offset by the fact all dep generating functions introduce () 
barriers to protect the invoking scope from their label adjustments.

Clarifying, this is better in labels:
"""
build+run:
  blah
run:
  monkeys
"""
equivalent in my proposal would be
"""
blah
dep:run? ( monkeys )
"""

The difference there isn't exactly world shattering, so it's not a 
strong arguing point for labels.


> > > Labels can give all the advantages of your proposal (including the
> > > backwards compatibility, if that's desired), but without the need to
> > > shoehorn the idea into an unsuitable syntax.
> > 
> > If you want your proposal to go anywhere, you're going to need a 
> > better transition plan then "and.... then devs convert their 
> > ebuilds/eclasses".  I'd suggested it prior, but no traction there.
> 
> Your "rewrite *DEPEND" approach can just as easily be used with labels.

Just the same as the real world usage of labels could just as easily 
be done via dep:blah.

Not sure it's worth continuing this discussion point frankly; there is 
equivalence for all real world usage.  Not really in dispute (you'll 
try I'm sure, but without actual backing examples this time around I'm 
not particularly interested in listening).

If what you've got to say is "you can do this in labels, and I think 
you should labels"; ok, noted, end of discussion.

Other points I'm interested in; the mentioning of "what does
!build:test? ( blah ) mean while in implicit build,run" for example 
was useful and a valid critique (one I've not yet addressed in the 
doc); stuff like that you've got a better chance killing my proposal 
then continuing with the "yes but labels are better than sliced bread.  
you just don't understand" angle of discussion ;)

Either way, via 
http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt 
, I think it's pretty clear labels in real world usage aren't bringing 
anything to the tabel that we wouldn't have via my proposal; that 
leaves labels as just a different syntax (perhaps aesthetically more 
pleasing at first glance, but the label stacking bit via exheres 
analysis is proven to be something people explicitly go out of their 
way to protect against; meaning the aesthetics have a mental 
model cost).

~harring

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2585 bytes --]

On Tue, 25 Sep 2012 15:46:14 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Fun fact; peoples usage of labels in exherbo is thus:
> 
> build+run:
>   set of deps
> run:
>   set of deps/conditionals/etc

That's largely because there are a lot of former Gentoo developers
there who all said "oh, yeah, I forgot we could do it the other way"
when this was pointed out...

> > Specification in terms of rendering has a huge problem, though.
> > Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what
> > does this do?
> > 
> >     || ( dep:build? ( a ) dep:run? ( b ) )
> 
> Honestly, I was waiting for you to bring this up :)
> 
> You're conflating two different things here;
> 1) someone being a dumb ass and writing what's effectively a || ( 
> atom) block, just doing so in a manner w/out any reason to do so.
> 
> 2) Your ongoing jihad against || (), specifically the occasionally 
> valid complaint that build/rdepend different means the resolver can 
> get stuck in certain pathways when slots are involved, abi, etc.
> 
> Either way, in my proposal, I'm not going to single that out and try 
> blocking it.  The rendered version of it is still stable, albeit if 
> it's build/run it's unlikely to be desired if there is ABI involved 
> (for non ABI, specifically self-bootstrapping codebases, I suspect 
> someone could come up with a valid construct- sed has something 
> similar if memory serves).

The rendered version ends up as ( a b ), in effect... It doesn't end up
as || ( a (at build time) b (at runtime) ).

> Which is stupid, but syntactically correct.  Nor is this a new issue, 
> thus I don't particularly agree with your approach of trying to sink 
> the proposal via an orthogonal problem.

No, you're introducing a new kind of weirdness for || ( ) here.

> Either way, via 
> http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt 
> , I think it's pretty clear labels in real world usage aren't
> bringing anything to the tabel that we wouldn't have via my proposal;
> that leaves labels as just a different syntax (perhaps aesthetically
> more pleasing at first glance, but the label stacking bit via exheres 
> analysis is proven to be something people explicitly go out of their 
> way to protect against; meaning the aesthetics have a mental 
> model cost).

It's not "go out of their way to protect against". It's "there's an
easy way of making sure everything is composable". Your
misappropriation of use flags doesn't have that.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Sat, Sep 29, 2012 at 05:05:09PM +0100, Ciaran McCreesh wrote:
> On Tue, 25 Sep 2012 15:46:14 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > Fun fact; peoples usage of labels in exherbo is thus:
> > 
> > build+run:
> >   set of deps
> > run:
> >   set of deps/conditionals/etc
> 
> That's largely because there are a lot of former Gentoo developers
> there who all said "oh, yeah, I forgot we could do it the other way"
> when this was pointed out...

I analyzed *all* exheres on git.exherbo.

To be crystal clear, these include your packages.

You yourself didn't use nested labels.  So either the author of labels 
'forgot' he could use it, or just didn't find the nesting actually 
useful.

Considering I've not found any examples where nesting /would/ be 
useful, I'm inclined to agree w/ y'alls usage- that nesting doesn't 
matter.

So... real world usage removes one of the core arguments of labels, 
leaving it just as "it's a new syntax/aesthetically more pleasing" in 
comparison to dep:build? ( blah ) form.

Not expecting you'll agree with that statement based on the facts of 
y'alls own repo... so if you're going to retort, bust out actual 
examples from eithe trees, where nesting would be preferable to the 
form people use now please; else just drop it (-your- own usage of 
labels disproves your claim; thus why I want actual examples now if 
that point will be debated any further).


> > > Specification in terms of rendering has a huge problem, though.
> > > Remembering the crazy rules Gentoo has for || ( flag? ( ) ), what
> > > does this do?
> > > 
> > >     || ( dep:build? ( a ) dep:run? ( b ) )
> > 
> > Honestly, I was waiting for you to bring this up :)
> > 
> > You're conflating two different things here;
> > 1) someone being a dumb ass and writing what's effectively a || ( 
> > atom) block, just doing so in a manner w/out any reason to do so.
> > 
> > 2) Your ongoing jihad against || (), specifically the occasionally 
> > valid complaint that build/rdepend different means the resolver can 
> > get stuck in certain pathways when slots are involved, abi, etc.
> > 
> > Either way, in my proposal, I'm not going to single that out and try 
> > blocking it.  The rendered version of it is still stable, albeit if 
> > it's build/run it's unlikely to be desired if there is ABI involved 
> > (for non ABI, specifically self-bootstrapping codebases, I suspect 
> > someone could come up with a valid construct- sed has something 
> > similar if memory serves).
> 
> The rendered version ends up as ( a b ), in effect... It doesn't end up
> as || ( a (at build time) b (at runtime) ).

Er, I assume you left out some chars there.  The rendered version 
there isn't ( a b ); in old form it is:
DEPEND=|| ( a )
RDEPEND=|| ( b )

This is why I label it a stupid use of syntax, but not ultimately 
harmful.


> > Which is stupid, but syntactically correct.  Nor is this a new issue, 
> > thus I don't particularly agree with your approach of trying to sink 
> > the proposal via an orthogonal problem.
> 
> No, you're introducing a new kind of weirdness for || ( ) here.

Na uh, you're the smelly face!

As I said, and via correcting your misrendering, this isn't 
introducing anything truly new here; people can/have done '|| ( a )'; 
it's a stupid construct, and for paludis it means it /does/ treat that 
as an OR block (for hte rest, we do the more obvious tree collapses 
during parsing, folding "a ( b )" down into "a b", same for "a || ( b 
)" into "a b" since they're the same thing).


> > Either way, via 
> > http://dev.gentoo.org/~ferringb/unified-dependencies/labels/translated-to-use-deps.txt 
> > , I think it's pretty clear labels in real world usage aren't
> > bringing anything to the tabel that we wouldn't have via my proposal;
> > that leaves labels as just a different syntax (perhaps aesthetically
> > more pleasing at first glance, but the label stacking bit via exheres 
> > analysis is proven to be something people explicitly go out of their 
> > way to protect against; meaning the aesthetics have a mental 
> > model cost).
> 
> It's not "go out of their way to protect against". It's "there's an
> easy way of making sure everything is composable". Your
> misappropriation of use flags doesn't have that.

Again, you're pulling a "na uh, you're the smelly face" counter 
argument.

Bluntly, you want something that is academically possible, but 
pragmatically/realistically unneeded- meaning the gains are basically 
not there, but the costs most definitely are.

Now, for exherbo were y'all lack actual versioned format (exheres-0 
has changed heavily since it's inception), and chucked everything and 
did it from scratch (right?  or do I need to do a copyright analysis 
in addition?)... the situation differs.  You can invent whatever 
syntax you want, since you're starting from scratch, changing the 
mental mode for parsing is fine.

We however are *not* starting from scratch.  This shifts what we'll 
accept for costs/gains ratio; frankly, the fact y'all don't make use 
of those claimed 'gains' makes me think y'all tried something and it 
turned out to be non-useful; it occurs in formats (ebuild format is 
littered w/ shit like that unfortunately).

Either way, this is gentoo, we're talking about the ebuild format; 
just the same as everyone shredded mgorny's ass for proposing we 
mangle atom syntax w/out gain, and proposal you push for the deptree 
changing, has to have significant gains for changing the existing 
form; aesthetics at a cost aren't enough.

~harring

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3196 bytes --]

On Sun, 30 Sep 2012 13:14:53 -0700
Brian Harring <ferringb@gmail.com> wrote:
> > That's largely because there are a lot of former Gentoo developers
> > there who all said "oh, yeah, I forgot we could do it the other way"
> > when this was pointed out...
> 
> I analyzed *all* exheres on git.exherbo.
> 
> To be crystal clear, these include your packages.
> 
> You yourself didn't use nested labels.  So either the author of
> labels 'forgot' he could use it, or just didn't find the nesting
> actually useful.

That's a rather disingenuous claim, considering how none of the
packages I maintain have any non-trivial dependencies... You could
equally well say that every single package I maintain makes use of
nested labels in every single place where they're relevant.

> So... real world usage removes one of the core arguments of labels, 
> leaving it just as "it's a new syntax/aesthetically more pleasing" in 
> comparison to dep:build? ( blah ) form.
> 
> Not expecting you'll agree with that statement based on the facts of 
> y'alls own repo... so if you're going to retort, bust out actual 
> examples from eithe trees, where nesting would be preferable to the 
> form people use now please; else just drop it (-your- own usage of 
> labels disproves your claim; thus why I want actual examples now if 
> that point will be debated any further).

It's not just that it's more aesthetically pleasing. There are two
arguments favouring labels over use abuse.

The first is that it doesn't have perverse behaviour associated with it
like your misappropriation of use conditionals does. If you put labels
deep in a tree, it's well defined. If you put your conditionals
anywhere except the top level, crazy stuff happens.

The second is that it starts the conceptual shift from "cat/pkg is a
build dep, and cat/pkg is a run dep" to "cat/pkg is a dep that is
required for build and run".

> Bluntly, you want something that is academically possible, but 
> pragmatically/realistically unneeded- meaning the gains are basically 
> not there, but the costs most definitely are.

No, I want something where things that are different look different.
Dependency types are nothing like use flags, so they shouldn't look the
same.

> Either way, this is gentoo, we're talking about the ebuild format; 
> just the same as everyone shredded mgorny's ass for proposing we 
> mangle atom syntax w/out gain, and proposal you push for the deptree 
> changing, has to have significant gains for changing the existing 
> form; aesthetics at a cost aren't enough.

The gain is that you have a syntax designed for what's being
represented, not an existing syntax abused to sort of (but not
quite, because it's still defined in terms of rendering down) do new
things.

Really, all it takes to see that your syntax is bad is one tiny little
example:

    dep:build? ( dep:run? ( cat/pkg ) )

There shouldn't be any need to add in a repoman check to catch that
kind of thing. The problem is entirely caused by bad syntax design.
Implementing labels is not difficult, and the extra cost is worth it to
get a good design.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Sun, Sep 30, 2012 at 09:30:18PM +0100, Ciaran McCreesh wrote:
> On Sun, 30 Sep 2012 13:14:53 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > > That's largely because there are a lot of former Gentoo developers
> > > there who all said "oh, yeah, I forgot we could do it the other way"
> > > when this was pointed out...
> > 
> > I analyzed *all* exheres on git.exherbo.
> > 
> > To be crystal clear, these include your packages.
> > 
> > You yourself didn't use nested labels.  So either the author of
> > labels 'forgot' he could use it, or just didn't find the nesting
> > actually useful.
> 
> That's a rather disingenuous claim, considering how none of the
> packages I maintain have any non-trivial dependencies... You could
> equally well say that every single package I maintain makes use of
> nested labels in every single place where they're relevant.

Admittedly, that was a punch nearing the belt or a bit below; that 
said it's not disenguous.

Reality is, our current form can handle deps generally fine- what you 
label as trivial is the vast majority- I argue effectively all.

And I intentionally gave you a way to disprove that; find real world 
dependency examples to disprove it.


> > So... real world usage removes one of the core arguments of labels, 
> > leaving it just as "it's a new syntax/aesthetically more pleasing" in 
> > comparison to dep:build? ( blah ) form.
> > 
> > Not expecting you'll agree with that statement based on the facts of 
> > y'alls own repo... so if you're going to retort, bust out actual 
> > examples from eithe trees, where nesting would be preferable to the 
> > form people use now please; else just drop it (-your- own usage of 
> > labels disproves your claim; thus why I want actual examples now if 
> > that point will be debated any further).
> 
> It's not just that it's more aesthetically pleasing. There are two
> arguments favouring labels over use abuse.
> 
> The first is that it doesn't have perverse behaviour associated with it
> like your misappropriation of use conditionals does. If you put labels
> deep in a tree, it's well defined. If you put your conditionals
> anywhere except the top level, crazy stuff happens.

This statement of yours however is fairly disenguous; label behaviour 
when nested suffers the same mental parsing oddity (wait, we're in 
build context, and this is test?  Wtf happens there?).  With 'use 
abuse' however, the situation is clear:

dep:build,run? ( x? ( dep:test? ( blah ) foon ) monkeys )

Means that 'blah' target doesn't show up.  Which is the *same* as what 
happens if someone did thus in our existing syntax:

x? ( !x? ( blah ) )

Worth noting, you didn't ban that from exherbo; you left that to sort 
itself out, same as I'm doing for dep:blah flags.  Were I punching 
below the belt, the word 'hypocritical' would likely be involved.


> The second is that it starts the conceptual shift from "cat/pkg is a
> build dep, and cat/pkg is a run dep" to "cat/pkg is a dep that is
> required for build and run".

Fairly weak argument at best; you're claiming that via labels, 
"contextually they know it's these deps" in comparison to via 
dep:build "contextually they know it's exposed only in build".

Same difference.


> > Bluntly, you want something that is academically possible, but 
> > pragmatically/realistically unneeded- meaning the gains are basically 
> > not there, but the costs most definitely are.
> 
> No, I want something where things that are different look different.
> Dependency types are nothing like use flags, so they shouldn't look the
> same.

I'll buy that argument, and to some degree- agree.

I just view that as academic wankery without real world gain.

So like I said, academically possible, but 
pragmatically/unrealistically unneded.

No amount of arguing is going to dissuade me on that view either, 
although real world tree examples *might*- aka, stop talking, go 
analyzing.


> > Either way, this is gentoo, we're talking about the ebuild format; 
> > just the same as everyone shredded mgorny's ass for proposing we 
> > mangle atom syntax w/out gain, and proposal you push for the deptree 
> > changing, has to have significant gains for changing the existing 
> > form; aesthetics at a cost aren't enough.
> 
> The gain is that you have a syntax designed for what's being
> represented, not an existing syntax abused to sort of (but not
> quite, because it's still defined in terms of rendering down) do new
> things.
> 
> Really, all it takes to see that your syntax is bad is one tiny little
> example:
> 
>     dep:build? ( dep:run? ( cat/pkg ) )

x? ( !x? ( cat/pkg ) )

Outlaw that in paludis/exherbo, and *perhaps* I'd listen to you.

You're going into broken record mode; the fact people can do stupid 
shit if they're willingly trying to abuse the syntax isn't much of an 
argument- especially considering the PM can handle it either way, 
rendering it out to a noop.


> There shouldn't be any need to add in a repoman check to catch that
> kind of thing. The problem is entirely caused by bad syntax design.
> Implementing labels is not difficult, and the extra cost is worth it to
> get a good design.

As I've said, there isn't a need for repoman checks.  It's *suggested* 
since as I've stated, the underlying idiocy should be spotted in our 
existing deps.

That said, repoman isn't necessary; such a construct solves itself via 
the deps dropping out; and before you try arguing that, your argument 
effectively would be based on "if someone specifies the deps wrong..." 
which means they're already up shit creek.

Either way, pulling another "done with this thread" bit to wrap this 
up; you don't like the proposal, got it.

In my proposal, I am addressing labels; will fold in your claims, but 
those claims basically are shit- however, if you *did* find a 
conflicting nested example that wasn't contrived, preferablly 
multiple, I'd like those examples so I can include them into the 
proposal (give labels a fair hand, basically).

I don't think you're going to find any, let alone one; some 
artificially structured ones perhaps, but I'm not interested in those- 
I'm looking for real world deps where conflicting nested is the best 
form.

Go find 'em; either way, moving on from the current discussion form 
(also known as "broken record mode").

cheers-
~harring

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3480 bytes --]

On Sun, 30 Sep 2012 14:42:14 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Reality is, our current form can handle deps generally fine- what you 
> label as trivial is the vast majority- I argue effectively all.

We could do away with half of the current feature set if we were only
interested in making things nice for the "vast majority" of cases...

> This statement of yours however is fairly disenguous; label behaviour 
> when nested suffers the same mental parsing oddity (wait, we're in 
> build context, and this is test?  Wtf happens there?).

No, label behaviour is local, and scope independent.

> Means that 'blah' target doesn't show up.  Which is the *same* as
> what happens if someone did thus in our existing syntax:
> 
> x? ( !x? ( blah ) )
> 
> Worth noting, you didn't ban that from exherbo; you left that to sort 
> itself out, same as I'm doing for dep:blah flags.  Were I punching 
> below the belt, the word 'hypocritical' would likely be involved.

That's "not fixing an existing screw-up", which is not the same at all
as "adding a new screw-up".

> > The second is that it starts the conceptual shift from "cat/pkg is a
> > build dep, and cat/pkg is a run dep" to "cat/pkg is a dep that is
> > required for build and run".
> 
> Fairly weak argument at best; you're claiming that via labels, 
> "contextually they know it's these deps" in comparison to via 
> dep:build "contextually they know it's exposed only in build".
> 
> Same difference.

It's rather a big deal now that we have := dependencies.

> > No, I want something where things that are different look different.
> > Dependency types are nothing like use flags, so they shouldn't look
> > the same.
> 
> I'll buy that argument, and to some degree- agree.
> 
> I just view that as academic wankery without real world gain.
> 
> So like I said, academically possible, but 
> pragmatically/unrealistically unneded.

Labels are almost as easy to implement as your "filtering" model, and
they come with the benefit of a better syntax for developers. Even if
labels are noticably more work to implement, which I'm not convinced is
the case, it's worth paying that price a couple of times in package
manglers rather than having developers pay the price of worse syntax in
thousands of ebuilds. Filtering is a whole new mechanism anyway.

But here's the thing: when you sell something as "pragmatic", what
you're really saying is "it's wrong, I know it's wrong, and I'm going
to pretend that wrong is a good thing". Getting it wrong should be
something you do only after you're sure you can't afford get it right;
it shouldn't be something you're proud of.

> In my proposal, I am addressing labels; will fold in your claims, but 
> those claims basically are shit- however, if you *did* find a 
> conflicting nested example that wasn't contrived, preferablly 
> multiple, I'd like those examples so I can include them into the 
> proposal (give labels a fair hand, basically).

You already have an example in your proposal, in the form of mplayer's
X? ( ) dependencies.

But that's missing the point. Even if you pretend complicated
dependencies don't exist, labels are still by far the better proposal.
Your argument boils down to "it's more pragmatic to do a quick and dirty
implementation in Portage and thus force the technical debt onto every
single ebuild than it is to do it cleanly".

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Sun, Sep 30, 2012 at 10:53:40PM +0100, Ciaran McCreesh wrote:
> But here's the thing: when you sell something as "pragmatic", what
> you're really saying is "it's wrong, I know it's wrong, and I'm going
> to pretend that wrong is a good thing". Getting it wrong should be
> something you do only after you're sure you can't afford get it right;
> it shouldn't be something you're proud of.

No, when I say pragmatic, what I'm actually saying is that people who 
can't focus on cost/gain, by large, haven't had real jobs (else they 
would've had that perfectionism/decreasing gains ground out of them 
sooner or later), and are spending their time whacking off chasing a 
mythical 'perfect' solution.

Academic wankery, is the short version.  You're good at technical, but 
you frequently do the academic wanking crap which leads to things 
dead-ending... plus wasted time because to you, 'pragmatic' is a dirty 
word (compromise?  Heaven forbid!).


> > In my proposal, I am addressing labels; will fold in your claims, but 
> > those claims basically are shit- however, if you *did* find a 
> > conflicting nested example that wasn't contrived, preferablly 
> > multiple, I'd like those examples so I can include them into the 
> > proposal (give labels a fair hand, basically).
> 
> You already have an example in your proposal, in the form of mplayer's
> X? ( ) dependencies.

I said nested conflicting labels.  Meaning 
"build: x? ( dar run: blah )"

which isn't the case for any of mplayer deps.

Actual examples from the tree where a conflicting nested label is 
preferable.  That isn't one of 'em, and you're unwillingness/inability 
to point out real world examples is just digging a deeper ditch for 
your argument.


> But that's missing the point. Even if you pretend complicated
> dependencies don't exist, labels are still by far the better proposal.
> Your argument boils down to "it's more pragmatic to do a quick and dirty
> implementation in Portage and thus force the technical debt onto every
> single ebuild than it is to do it cleanly".

My argument boils down to thus:

We are not exherbo- we do not have the luxury of chucking out syntax 
and pulling NIH renaming of things for shits and giggles.  Especially 
if the new syntax is directly translatable into a tweak of our 
existing syntax (a tweak that we should do anyways- recall I built 
this off of fixing USE_EXPAND).

Your argument boils down to "it's not labels, ignore that it's 
aesthetic knob polishing (you can do the same w/ our existent 
syntax, thus the analogy of waxing it I truly mean), use labels 
because I'll berate you incessently till you accede".

Beauty of open source, you want it, go do it.

If in, what, 4 years?  3?  You've not been able to get off your ass, 
write a proposal, hell, do a portage patch (you've *never* done 
portage patches of any worth, bluntly- I know this since in the past I 
used to fix shit you requested), you lose your voice in the matter.

Considering your points boil down to aesthetic academic wanking at 
this point... put up, or shut up, really is that simple.

As said, you come up w/ real world examples, I'll include them; else 
persist and I'll just fold the academic wankery description of labels 
into the glep if you'd truly like me to (or you piss me off enough I 
do so to be a dick).

~harring

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3620 bytes --]

On Sun, 30 Sep 2012 16:56:56 -0700
Brian Harring <ferringb@gmail.com> wrote:
> On Sun, Sep 30, 2012 at 10:53:40PM +0100, Ciaran McCreesh wrote:
> > But here's the thing: when you sell something as "pragmatic", what
> > you're really saying is "it's wrong, I know it's wrong, and I'm
> > going to pretend that wrong is a good thing". Getting it wrong
> > should be something you do only after you're sure you can't afford
> > get it right; it shouldn't be something you're proud of.
> 
> No, when I say pragmatic, what I'm actually saying is that people who 
> can't focus on cost/gain, by large, haven't had real jobs (else they 
> would've had that perfectionism/decreasing gains ground out of them 
> sooner or later), and are spending their time whacking off chasing a 
> mythical 'perfect' solution.

I don't know whether you're aware of this, but a small number (cost per
ebuild) multiplied by a big number (lots of ebuilds) can be larger than
a medium sized number (cost of implementing a good solution). I realise
this is a sophisticated technique I'm using here, but I assure you
multiplication has been used in some industries for a few years now.

> Academic wankery, is the short version.  You're good at technical,
> but you frequently do the academic wanking crap which leads to things 
> dead-ending... plus wasted time because to you, 'pragmatic' is a
> dirty word (compromise?  Heaven forbid!).

Or looking at it another way: you're so eager to deliver a "compromise"
and a "pragmatic" solution (at the expense of ebuild writers
everywhere) that you immediately rule out a "good" solution just so
you can push the virtues of doing it wrong. Doing it wrong should be a
last resort, not something you look to do at any given opportunity.

> > > In my proposal, I am addressing labels; will fold in your claims,
> > > but those claims basically are shit- however, if you *did* find a 
> > > conflicting nested example that wasn't contrived, preferablly 
> > > multiple, I'd like those examples so I can include them into the 
> > > proposal (give labels a fair hand, basically).
> > 
> > You already have an example in your proposal, in the form of
> > mplayer's X? ( ) dependencies.
> 
> I said nested conflicting labels.  Meaning 
> "build: x? ( dar run: blah )"
> 
> which isn't the case for any of mplayer deps.

x? ( build: a run: b ) *is* nested "conflicting".

You're still failing to understand the point of labels parsing rules,
though: the point is to make uses like the above well defined and
consistent.

> We are not exherbo- we do not have the luxury of chucking out syntax 
> and pulling NIH renaming of things for shits and giggles.  Especially 
> if the new syntax is directly translatable into a tweak of our 
> existing syntax (a tweak that we should do anyways- recall I built 
> this off of fixing USE_EXPAND).

This isn't chucking out syntax. It's augmenting existing syntax. What
you're doing is trying to shove something new onto an existing syntax
which doesn't fit it.

You should know this from REQUIRED_USE: that's a perfect example of
going too far to reuse existing syntax.

> Your argument boils down to "it's not labels, ignore that it's 
> aesthetic knob polishing (you can do the same w/ our existent 
> syntax, thus the analogy of waxing it I truly mean), use labels 
> because I'll berate you incessently till you accede".

It's about giving ebuild developers a good format to work with. That
sort of thing matters. There are a lot of ebuilds and not many package
manglers.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Mon, Oct 01, 2012 at 08:13:49AM +0100, Ciaran McCreesh wrote:
> x? ( build: a run: b ) *is* nested "conflicting".
> 
> You're still failing to understand the point of labels parsing rules,
> though: the point is to make uses like the above well defined and
> consistent.

I understand them just fine; you're just either very fucking daft, 
which I have a hard time believing, or lieing through your teeth 
(which fits a decade of behaviour including multiple suspensions for 
exactly that behaviour).

Implicit labels context is build+run.  Meaning the following
> x? ( build: a run: b ) *is* nested "conflicting".

is actually

build+run x? ( build: a run: b )

Which isn't a nested conflict- subset, not conflict.

You argue labels are required so people can do nested conflicts; 
meaning the following extreme example:

run x? ( build: a test: b )

And as I nicely pointed out, /not a single fucking exheres/ does that.  
you've yet to pull out an example contradicting that analysis in 
addition.


So... with that in mind- I'm doing two things; 1) can't force you 
back under a bridge, instead I'll do the killfile equivalent for a few 
weeks, 2) my original proposal if you kept being a tool seems 
appropriate:

"""
As said, you come up w/ real world examples, I'll include them; else
persist and I'll just fold the academic wankery description of labels
into the glep if you'd truly like me to (or you piss me off enough I
do so to be a dick).
"""

What I truly love about that solution there is that it's both 
accurate, and if I play my cards right, I may be able to get a glep 
passed calling your proposal academic wankery; minimally, it'll be fun 
from my standpoint to try, so at least something came out of the last 
few emails from you.

hugs and kisses-
~harring

[gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2436 bytes --]

On Mon, 1 Oct 2012 02:01:32 -0700
Brian Harring <ferringb@gmail.com> wrote:
> On Mon, Oct 01, 2012 at 08:13:49AM +0100, Ciaran McCreesh wrote:
> > x? ( build: a run: b ) *is* nested "conflicting".
> > 
> > You're still failing to understand the point of labels parsing
> > rules, though: the point is to make uses like the above well
> > defined and consistent.
> 
> I understand them just fine; you're just either very fucking daft, 
> which I have a hard time believing, or lieing through your teeth 
> (which fits a decade of behaviour including multiple suspensions for 
> exactly that behaviour).
> 
> Implicit labels context is build+run.  Meaning the following
> > x? ( build: a run: b ) *is* nested "conflicting".
> 
> is actually
> 
> build+run x? ( build: a run: b )
> 
> Which isn't a nested conflict- subset, not conflict.

As I said right at the start, you're special-casing the top level to
something that can't normally be expressed using the syntax.

> You argue labels are required so people can do nested conflicts; 
> meaning the following extreme example:
> 
> run x? ( build: a test: b )
> 
> And as I nicely pointed out, /not a single fucking exheres/ does
> that. you've yet to pull out an example contradicting that analysis
> in addition.

No, I argue that having well-defined parsing rules means it doesn't
matter if someone does do that. Meaning, no special case for the top
level.

Your rules require a handler to say "have I seen any dep: blocks
further up the tree than my current position? If yes, handle this dep:
block one way; otherwise, handle it a different way". With labels, all
you do is initialise the label stack with build+run, and then no
special case handling is required.

That's what you should be putting in the GLEP. Not examples, but a big
fat warning that your syntax requires a very strange special case rule
to handle your default build+run behaviour.

> What I truly love about that solution there is that it's both 
> accurate, and if I play my cards right, I may be able to get a glep 
> passed calling your proposal academic wankery; minimally, it'll be
> fun from my standpoint to try, so at least something came out of the
> last few emails from you.

Oh come on, we all know that unnecessarily screwing up the syntax won't
make DEPENDENCIES be sufficiently un-exherbo-looking to get it passed...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: GLEP: gentoo sync based unified deps proposal

[Steven J. Long]

On Mon, Oct 01, 2012 at 10:15:31AM +0100, Ciaran McCreesh wrote:
> On Mon, 1 Oct 2012 02:01:32 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > Implicit labels context is build+run.

<snip>
> Your rules require a handler to say "have I seen any dep: blocks
> further up the tree than my current position? If yes, handle this dep:
> block one way; otherwise, handle it a different way".

Given that there's an implicit top-level, that's always a "yes" so there
is no such "special"-case decision required.

> With labels, all
> you do is initialise the label stack with build+run, and then no
> special case handling is required.
>
In practical terms, that's the exact same thing as initialising with a
defined context. And as shown, your proof of "special-case" is bogus.

 
Looking at both your arguments, I agree with Harring that they amount
to the same thing. But as he also said: "changing the mental mode for 
parsing" has a cost, and "We however are *not* starting from scratch.
This shifts what we'll accept for costs/gains ratio." So any change
"has to have significant gains for changing the existing form."

The problem is that you're both thinking in terms of what the package
mangler wants, and not in terms of how people think. When you try to
build a package from source, the first thing you ask is "What libraries
does it need?" Then "What tools do I need at build-time to compile it?"
"How do I configure the package, and what's the effect in
terms of functionality and dependencies if I tell it not to use specific
libraries, which I might not have or want to download?"
Then "What does it need on the host system to run it (given that I've
already installed the libraries or it wouldn't have built)?"

See how those map to simple variables and USE flags, that people are
used to handling? That's why ports does it like that, and that's why the
format was copied (in simplified form to ease implementation) for portage.

The only shown advantage in your methods is a quicker cache format, which
can be inferred from the existing syntax, and would thus never even hit
user machines, if you just used it in the cache.

And for that, you want to radically change the way everyone writes ebuilds,
along with all the maintenance headaches, instead of adding a variable that
plugs the gap in the original spec.

Oh, and some putative ability to arbitrarily add new labels in the
hypothetical future, all specified in terms of package manager internals.
You're getting it wrong: those flow (and should be inferred) from the
roles that the various dependencies play in the build process, not the
other way round. Roles named by declarative variables, that match the
mental model people have of the build process.

That way your format supports its users in a transparent manner, instead 
of making them jump thru hoops and learn more and more obscure syntax,
along with new, more complex, ways of doing the same thing you were doing
before without the headache.

Just agree a format, and use it in the cache, already.

Or y'know, don't call it an ebuild.
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/09/12 05:53 PM, Ciaran McCreesh wrote:
> On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring
> <ferringb@gmail.com> wrote:
>>> The second is that it starts the conceptual shift from "cat/pkg
>>> is a build dep, and cat/pkg is a run dep" to "cat/pkg is a dep
>>> that is required for build and run".
>> 
>> Fairly weak argument at best; you're claiming that via labels, 
>> "contextually they know it's these deps" in comparison to via 
>> dep:build "contextually they know it's exposed only in build".
>> 
>> Same difference.
> 
> It's rather a big deal now that we have := dependencies.
> 

So you would using your labels syntax, specify an atom with a := dep
using certain labels and the same atom without ':=' on other labels?
I don't quite follow what you're getting at here as to how this is a
big deal..

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBrKYUACgkQ2ugaI38ACPAMJAD9FzCH4ifbkanbC17w2KGjMHP7
G4qBrJ9v2dd7sHV338EA/iK/J+NZosc+M7wefJ8J6fU4mVczlM4WiOkCNVsTSO6w
=Io2B
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 02 Oct 2012 13:51:01 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> On 30/09/12 05:53 PM, Ciaran McCreesh wrote:
> > On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring
> > <ferringb@gmail.com> wrote:
> >>> The second is that it starts the conceptual shift from "cat/pkg
> >>> is a build dep, and cat/pkg is a run dep" to "cat/pkg is a dep
> >>> that is required for build and run".
> >> 
> >> Fairly weak argument at best; you're claiming that via labels, 
> >> "contextually they know it's these deps" in comparison to via 
> >> dep:build "contextually they know it's exposed only in build".
> >> 
> >> Same difference.
> > 
> > It's rather a big deal now that we have := dependencies.
> > 
> 
> So you would using your labels syntax, specify an atom with a := dep
> using certain labels and the same atom without ':=' on other labels?
> I don't quite follow what you're getting at here as to how this is a
> big deal..

A := only makes sense for a dependency that is present both at build
time and at runtime. Currently, the only place you should be seeing
a := is on a spec that is listed in both DEPEND and RDEPEND.

Conceptually, the := applies to "the spec that is in both DEPEND and
RDEPEND". But with the current syntax, there's no such thing as "the
spec that is in both". There are two specs, which happen to be
identical as strings, one in DEPEND and one in RDEPEND, and there's no
way for the two to be associated.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBrKsEACgkQ96zL6DUtXhEyOACfQgN7K9iPf0o8NF4w95HpFq3j
MHQAoKwMwmbJHuF65PIX9b6W0EQLqukl
=pzQn
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 02/10/12 01:56 PM, Ciaran McCreesh wrote:
> On Tue, 02 Oct 2012 13:51:01 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
>> On 30/09/12 05:53 PM, Ciaran McCreesh wrote:
>>> On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring 
>>> <ferringb@gmail.com> wrote:
>>>>> The second is that it starts the conceptual shift from
>>>>> "cat/pkg is a build dep, and cat/pkg is a run dep" to
>>>>> "cat/pkg is a dep that is required for build and run".
>>>> 
>>>> Fairly weak argument at best; you're claiming that via
>>>> labels, "contextually they know it's these deps" in
>>>> comparison to via dep:build "contextually they know it's
>>>> exposed only in build".
>>>> 
>>>> Same difference.
>>> 
>>> It's rather a big deal now that we have := dependencies.
>>> 
> 
>> So you would using your labels syntax, specify an atom with a :=
>> dep using certain labels and the same atom without ':=' on other
>> labels? I don't quite follow what you're getting at here as to
>> how this is a big deal..
> 
> A := only makes sense for a dependency that is present both at
> build time and at runtime. Currently, the only place you should be
> seeing a := is on a spec that is listed in both DEPEND and
> RDEPEND.
> 
> Conceptually, the := applies to "the spec that is in both DEPEND
> and RDEPEND". But with the current syntax, there's no such thing as
> "the spec that is in both". There are two specs, which happen to
> be identical as strings, one in DEPEND and one in RDEPEND, and
> there's no way for the two to be associated.
> 

Current syntax = *DEPEND, yes.  Completely agree.

In relation to Brian's proposal for DEPENDENCIES, tho, the two specs
which happen to be identical strings would be rolled out from the same
- -actual- string in the ebuild, and so, I don't see any such 'big deal'
between the ability to conceptually express what's going on via his
syntax and your labels.

Unless i'm missing something, 'same difference' still fits..

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBrLYIACgkQ2ugaI38ACPBb4gD+KnH0izbhJZuhm0JD1cHG6s0D
4/0gxZk3Z+TEy9I0W84A/1Yt0ilqJ0SfNTHr9P6hjQkUvLsHzPzkh4Kiz8VMah/w
=8amf
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 02 Oct 2012 14:08:02 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> > A := only makes sense for a dependency that is present both at
> > build time and at runtime. Currently, the only place you should be
> > seeing a := is on a spec that is listed in both DEPEND and
> > RDEPEND.
> > 
> > Conceptually, the := applies to "the spec that is in both DEPEND
> > and RDEPEND". But with the current syntax, there's no such thing as
> > "the spec that is in both". There are two specs, which happen to
> > be identical as strings, one in DEPEND and one in RDEPEND, and
> > there's no way for the two to be associated.
> > 
> 
> Current syntax = *DEPEND, yes.  Completely agree.
> 
> In relation to Brian's proposal for DEPENDENCIES, tho, the two specs
> which happen to be identical strings would be rolled out from the same
> - -actual- string in the ebuild, and so, I don't see any such 'big
> deal' between the ability to conceptually express what's going on via
> his syntax and your labels.
> 
> Unless i'm missing something, 'same difference' still fits..

Brian has DEPENDENCIES as being syntactic sugar that is "rendered" into
separate *DEPEND variables. Conceptually, a := spec would be treated as
two different, unrelated specs. If we're doing that, though, then
there's not really any point in the proposal -- we want the model
change, not just for := dependencies, but also to allow us to fix some
of the awful mess that is ||.

- -- 
Ciaran McCreesh
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iEYEARECAAYFAlBrL2kACgkQ96zL6DUtXhE1EgCeNANLVxtyb6OSir9LqA+PB+bJ
zUkAn2dV2OjMYMB95+tBUYvb3Eda4rU7
=0Cwb
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Tue, Oct 02, 2012 at 02:08:02PM -0400, Ian Stakenvicius wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> On 02/10/12 01:56 PM, Ciaran McCreesh wrote:
> > On Tue, 02 Oct 2012 13:51:01 -0400 Ian Stakenvicius
> > <axs@gentoo.org> wrote:
> >> On 30/09/12 05:53 PM, Ciaran McCreesh wrote:
> >>> On Sun, 30 Sep 2012 14:42:14 -0700 Brian Harring 
> >>> <ferringb@gmail.com> wrote:
> >>>>> The second is that it starts the conceptual shift from
> >>>>> "cat/pkg is a build dep, and cat/pkg is a run dep" to
> >>>>> "cat/pkg is a dep that is required for build and run".
> >>>> 
> >>>> Fairly weak argument at best; you're claiming that via
> >>>> labels, "contextually they know it's these deps" in
> >>>> comparison to via dep:build "contextually they know it's
> >>>> exposed only in build".
> >>>> 
> >>>> Same difference.
> >>> 
> >>> It's rather a big deal now that we have := dependencies.
> >>> 
> > 
> >> So you would using your labels syntax, specify an atom with a :=
> >> dep using certain labels and the same atom without ':=' on other
> >> labels? I don't quite follow what you're getting at here as to
> >> how this is a big deal..
> > 
> > A := only makes sense for a dependency that is present both at
> > build time and at runtime. Currently, the only place you should be
> > seeing a := is on a spec that is listed in both DEPEND and
> > RDEPEND.
> > 
> > Conceptually, the := applies to "the spec that is in both DEPEND
> > and RDEPEND". But with the current syntax, there's no such thing as
> > "the spec that is in both". There are two specs, which happen to
> > be identical as strings, one in DEPEND and one in RDEPEND, and
> > there's no way for the two to be associated.
> > 
> 
> Current syntax = *DEPEND, yes.  Completely agree.
> 
> In relation to Brian's proposal for DEPENDENCIES, tho, the two specs
> which happen to be identical strings would be rolled out from the same
> - -actual- string in the ebuild, and so, I don't see any such 'big deal'
> between the ability to conceptually express what's going on via his
> syntax and your labels.
> 
> Unless i'm missing something, 'same difference' still fits..

Same difference applies; he's making the claim that the resolver can't 
tell that the python atom should be the same between build/run:

dep:build,run? ( dev-lang/python:2.7= )
build: dev-python/snakeoil

# vs labels

build+run: dev-lang/python:2.7=
build: dev-python/snakeoil

The argument there is basically predicated on the belief that only 
labels can 'color' the sections it contains.  This is a bullshit 
claim, and possibly specific to paludis internal failings.

A sane implementation can walk that parse tree, and minimally infer 
that on it's own via the walk- or if it's saner, just track where 
things came from, and sort it via that way.  Realistically a *good* 
implementation would likely be doing a partial rendering anyways (a 
good implementation already has the machinery for this for QA analysis 
reasons)- meaning conditionals beyond dep: would be finalized, leaving 
just those nodes unrendered, and then doing quick pass rendering of 
that intermediate form to get each phases specific requirements.

Honestly it's a bullshit argument anyways; the unstated, but core 
argument of such nonsense is that the resolver if it saw

dep:build? ( dev-lang/python:2.7= )
dep:run? ( dev-lang/python:2.7= )

would, because it's not one single build/run construct, think it can 
vary python:2.7  Any/all sane resolver already do collapsing and 
stabilization of common nodes across dep phases (and if paludis 
doesn't, well, that's their mess to sort; we're not getting any 
PROPERTIES=funky-slots hacks to work around their brain dead 
breakage here).

The same situation can occur w/ labels via eclass dep manipulation; 
this is an artificial example, but anyone who has done deps know this 
sort of thing can/does occur via eclasses injecting common deps in:

encode? ( build: dev-lang/python:2.7= )
build,run: dev-lang/python:2.7=

Oh noes.  How ever will the resolver know that it shouldn't vary the 
micro version of dev-lang/python:2.7 between build and run in that 
case!  You just *know* it wants to vary the micro version because, 
such a completely fucking worthless thing for the resolver, it must do 
because it can, right?

Etc.  It's a pure bullshit argument, potentially derived from 
implementation issues for his own code, or just academic wankery; 
unsure of which, don't care which since the core argument is a 
new level of cracked out.

~harring

Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On Tue, 2 Oct 2012 13:40:45 -0700
Brian Harring <ferringb@gmail.com> wrote:
> Same difference applies; he's making the claim that the resolver
> can't tell that the python atom should be the same between build/run:
> 
> dep:build,run? ( dev-lang/python:2.7= )
> build: dev-python/snakeoil
> 
> # vs labels
> 
> build+run: dev-lang/python:2.7=
> build: dev-python/snakeoil
> 
> The argument there is basically predicated on the belief that only 
> labels can 'color' the sections it contains.  This is a bullshit 
> claim, and possibly specific to paludis internal failings.

No, it's specific to failings in the way you've written your proposal,
which in turn are due to you wanting to implement it as a quick
rendering hack in Portage.

Unfortunately, the way you define things in terms of rendering
dependencies forces everyone to emulate these failings so as to deliver
a compliant handling of the || ( dep:build? ( a ) dep:run? ( b ) )
case.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Steven J. Long]

On Tue, Oct 02, 2012 at 06:56:14PM +0100, Ciaran McCreesh wrote:
> A := only makes sense for a dependency that is present both at build
> time and at runtime. Currently, the only place you should be seeing
> a := is on a spec that is listed in both DEPEND and RDEPEND.
> 
> Conceptually, the := applies to "the spec that is in both DEPEND and
> RDEPEND". But with the current syntax, there's no such thing as "the
> spec that is in both". There are two specs, which happen to be
> identical as strings, one in DEPEND and one in RDEPEND, and there's no
> way for the two to be associated.
> 
Now that *is* dishonestly ignorant: you know full well that LDEPEND [1]
covers exactly that case.

As well as obviating the need for := in the cases that break installs.

And oh look, "required before build, but must be installed in ROOT, not
on BUILD machine"; now where have I heard that requirement before?

So there is a very easy way for the two to be associated, and to specify
the most common (or any other, should it be justified) dependency that
is in both, with the current syntax.

But you knew that, right? You just chose to ignore it. Tsk: that's hardly
academically rigorous. Bad form, old chap, simply bad form.

[1] http://article.gmane.org/gmane.linux.gentoo.devel/80653
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 952 bytes --]

On Sun, 14 Oct 2012 17:45:13 +0100
"Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:
> On Tue, Oct 02, 2012 at 06:56:14PM +0100, Ciaran McCreesh wrote:
> > A := only makes sense for a dependency that is present both at build
> > time and at runtime. Currently, the only place you should be seeing
> > a := is on a spec that is listed in both DEPEND and RDEPEND.
> > 
> > Conceptually, the := applies to "the spec that is in both DEPEND and
> > RDEPEND". But with the current syntax, there's no such thing as "the
> > spec that is in both". There are two specs, which happen to be
> > identical as strings, one in DEPEND and one in RDEPEND, and there's
> > no way for the two to be associated.
> > 
> Now that *is* dishonestly ignorant: you know full well that LDEPEND
> [1] covers exactly that case.

Everyone else knows full well that LDEPEND is such a badly broken idea
that it's not worth discussing...

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: Re: Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Steven J. Long]

On Sun, Oct 14, 2012 at 05:38:06PM +0100, Ciaran McCreesh wrote:
> "Steven J. Long" <slong@rathaus.eclipse.co.uk> wrote:
> > On Tue, Oct 02, 2012 at 06:56:14PM +0100, Ciaran McCreesh wrote:
> > > But with the current syntax, there's no such thing as "the
> > > spec that is in both". There are two specs, which happen to be
> > > identical as strings, one in DEPEND and one in RDEPEND, and there's
> > > no way for the two to be associated.
> > > 
> > Now that *is* dishonestly ignorant: you know full well that LDEPEND
> > [1] covers exactly that case.
> 
> Everyone else knows full well that LDEPEND is such a badly broken idea
> that it's not worth discussing...

*sigh* and as usual you ignore the actual point:

> So there is a very easy way for the two to be associated, and to specify
> the most common (or any other, should it be justified) dependency that
> is in both, with the current syntax.

Irrespective of which variable we discuss, the fact remains that it is
perfectly possible to specify a dependency that is in both, addressing
the points raised by Harring, which are actually your concerns.

Except you couldn't be bothered to outline those, just like you are hand-
waving now.

Again, I am left wondering just what kind of academics Cambridge is
producing nowadays.

-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Re: [gentoo-dev] Re: [gentoo-pms] GLEP: gentoo sync based unified deps proposal

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 16/09/12 12:05 PM, Brian Harring wrote:
> On Sun, Sep 16, 2012 at 03:39:49PM +0100, Ciaran McCreesh wrote:
>> There's also the issue of what negations do at the top level...
> 
> Yeah, I did skimp on that one; technically speaking, negations
> aren't required if they prove too much of a pain in the ass.
> Negation at the top level could be interpretted two ways:
> 
> 1) negating against all possible dep types; thus a !dep:build?
> would be dep:post,run? .  Too slick in my view, but who knows,
> othes may think it straight forward.
> 
> 2) Treat it as a negation of the implicit dep:build,run; meaning 
> !dep:build? would be dep:run?.
> 
> Unsure of which is preferably at this juncture.
> 

Proposal:  Negation only works within the current context.  Simpler to
understand that way.  So if the implicit dep:build,run is going to be
kept (iirc the glep says this is optional and for convenience, so if
we dropped it in favour of always forcing it that might be good), #2
would apply.

This would also infer that:

dep:build? ( !dep:{anything but build}? ( something ) ) would have no
meaning and the "!dep:{anything but build}?" condition would just be
ignored.  Probably, without a QA warning since I could see eclasses
perhaps providing something in a variable or function output that
might be processed in this manner.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF0EAREIAAYFAlBYdqYACgkQ2ugaI38ACPB41gD4ygy9SxFODJb/TlUp+23cZ36s
D+/c6gCaGXIPVoDGlQD/fsE6TcBsDnovBTVA0db4s811rTuih7JpX5LRDuABjfk=
=0eGL
-----END PGP SIGNATURE-----

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

On Sep 16, 2012 4:55 PM, "Brian Harring" <ferringb@gmail.com> wrote:
>
> Folks-
>
> Keeping it short and quick, a basic glep has been written for what I'm
> proposing for DEPENDENCIES enhancement.
>
> The live version of the doc is available at
>
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html

Am I the only one who thinks that this dep:{build,...} thing looks really
ugly and is hard to read?

IMO simply removing the "dep" part would greatly improve things:

DEPENDENCIES="
:build,run? ( ... )
:run? ( ... )
"

s/:/@/ would also be interesting

DEPENDENCIES="
@build,run? ( ... )
@run? ( ... )
"

Alex | wired

[-- Attachment #2: Type: text/html, Size: 1031 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ulrich Mueller]

>>>>> On Sun, 16 Sep 2012, Alex Alexander wrote:

> Am I the only one who thinks that this dep:{build,...} thing looks
> really ugly and is hard to read?

+1

> IMO simply removing the "dep" part would greatly improve things:

> DEPENDENCIES="
> :build,run? ( ... )
> :run? ( ... )
> "

IMHO it would improve readability even more if we would stay with our
traditional *DEPEND variables. In any case, package managers will have
to support them indefinitely for existing EAPIs.

Ulrich

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:
>    On Sep 16, 2012 4:55 PM, "Brian Harring" <[1]ferringb@gmail.com> wrote:
>    >
>    > Folks-
>    >
>    > Keeping it short and quick, a basic glep has been written for what
>    I'm
>    > proposing for DEPENDENCIES enhancement.
>    >
>    > The live version of the doc is available at
>    >
>    [2]http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe
>    ndencies.html
> 
>    Am I the only one who thinks that this dep:{build,...} thing looks
>    really ugly and is hard to read?
> 
>    IMO simply removing the "dep" part would greatly improve things:

That 'dep' part isn't great, but it's added for a reason; to unify 
with USE_EXPAND/use group intended syntax.  There's a reference in 
there to 
http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which 
I'll formalize soon enough.


>    DEPENDENCIES="
>    :build,run? ( ... )
>    :run? ( ... )
>    "

For your suggestion, consider it if we *do* fxi USE expand- via using 
the same <namespace>:<setting> form.

Using app-admin/mcollective ad an example, it's deps are thus:

DEPEND="ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
        ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
RDEPEND="dev-ruby/stomp
        ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
        ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"

Which, if USE_EXPAND targets were groupped, would go from this
  ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
  ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
  dep:run? ( dev-ruby/stomp )"

to this:
  ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
  ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
  :run? ( dev-ruby/stomp )



>    s/:/@/ would also be interesting

Just a note; the character choosen was *intentionally* one that isn't 
a valid use character.  @ is a valid character due to linguas.  See 
the thread I referenced (ciaran's response, then my response).

Short version; to use @, we need use subgroups; thus
linguas@ca@valencia .


>    DEPENDENCIES="
>    @build,run? ( ... )
>    @run? ( ... )
>    "

DEPENDENCIES="
  ruby@targets_ruby18? ( dev-lang/ruby:1.8 )
  ruby@targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
  @run? ( dev-ruby/stomp )"

Using equivalent syntax for mcollective.

I'm not a huge fan of dep:, and I'm a bit wary of a bare 
@{run,test,whatever} since it carries with it an implicit "this is 
targetting the dep namespace".

That said, I'm not opposed to it- just as I said, I'm a bit wary at 
first glance.

Comments?
~harring

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Peter Stuge]

Brian Harring wrote:
> Comments?

: is used for namespaces elsewhere too. The familiarity is good.


//Peter

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Alex Alexander]

[-- Attachment #1: Type: text/plain, Size: 2985 bytes --]

On Sep 17, 2012 6:13 AM, "Brian Harring" <ferringb@gmail.com> wrote:
>
> On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:
> >    On Sep 16, 2012 4:55 PM, "Brian Harring" <[1]ferringb@gmail.com>
wrote:
> >    >
> >    > Folks-
> >    >
> >    > Keeping it short and quick, a basic glep has been written for what
> >    I'm
> >    > proposing for DEPENDENCIES enhancement.
> >    >
> >    > The live version of the doc is available at
> >    >
> >    [2]
http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe
> >    ndencies.html
> >
> >    Am I the only one who thinks that this dep:{build,...} thing looks
> >    really ugly and is hard to read?
> >
> >    IMO simply removing the "dep" part would greatly improve things:
>
> That 'dep' part isn't great, but it's added for a reason; to unify
> with USE_EXPAND/use group intended syntax.  There's a reference in
> there to
> http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which
> I'll formalize soon enough.
>
>
> >    DEPENDENCIES="
> >    :build,run? ( ... )
> >    :run? ( ... )
> >    "
>
> For your suggestion, consider it if we *do* fxi USE expand- via using
> the same <namespace>:<setting> form.
>
> Using app-admin/mcollective ad an example, it's deps are thus:
>
> DEPEND="ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>         ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
> RDEPEND="dev-ruby/stomp
>         ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>         ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
>
> Which, if USE_EXPAND targets were groupped, would go from this
>   ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>   ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
>   dep:run? ( dev-ruby/stomp )"
>
> to this:
>   ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
>   ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
>   :run? ( dev-ruby/stomp )

Ok, now I get it. I've read the other threads as well, but failed to put it
all together. Happens when you barely sleep every night :-)

I don't like this mix of dependency types and use flag deps. It smells
trouble. Dependency types should be easy to separate and read, but the
above example is a mess, "dep:" or no "dep:".

Why? Because you have to scan the whole thing to sort out which lines are
dependency types and which lines are use deps and even then it would be
easy to misread something.

If we want to stay away from labels (which aren't that bad IMO), I'd
recommend the following instead:

Force explicit setting of the dependency type and disallow the mix of
dependency types and use flag deps at the same level / block.

DEPENDENCIES="
  :build,run? ( lib/foo )
  :run? (
    lib/bar
    someuseflag? ( random/app )
  )
  :*? (
    thing? (
      :build? ( lib/thing )
      :run? ( lib/thingrunner )
    )
"

Or, using your example:

:build,run? (
  ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
  ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
)
:run? ( dev-ruby/stomp )

Alex | wired

[-- Attachment #2: Type: text/html, Size: 4043 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ben de Groot]

On 17 September 2012 18:55, Alex Alexander <alex.alexander@gmail.com> wrote:
> On Sep 17, 2012 6:13 AM, "Brian Harring" <ferringb@gmail.com> wrote:
>>
>> On Sun, Sep 16, 2012 at 07:32:39PM +0300, Alex Alexander wrote:
>> >    On Sep 16, 2012 4:55 PM, "Brian Harring" <[1]ferringb@gmail.com>
>> > wrote:
>> >    >
>> >    > Folks-
>> >    >
>> >    > Keeping it short and quick, a basic glep has been written for what
>> >    I'm
>> >    > proposing for DEPENDENCIES enhancement.
>> >    >
>> >    > The live version of the doc is available at
>> >    >
>> >
>> > [2]http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_depe
>> >    ndencies.html
>> >
>> >    Am I the only one who thinks that this dep:{build,...} thing looks
>> >    really ugly and is hard to read?
>> >
>> >    IMO simply removing the "dep" part would greatly improve things:
>>
>> That 'dep' part isn't great, but it's added for a reason; to unify
>> with USE_EXPAND/use group intended syntax.  There's a reference in
>> there to
>> http://www.gossamer-threads.com/lists/gentoo/dev/260069#260069 which
>> I'll formalize soon enough.
>>
>>
>> >    DEPENDENCIES="
>> >    :build,run? ( ... )
>> >    :run? ( ... )
>> >    "
>>
>> For your suggestion, consider it if we *do* fxi USE expand- via using
>> the same <namespace>:<setting> form.
>>
>> Using app-admin/mcollective ad an example, it's deps are thus:
>>
>> DEPEND="ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>>         ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
>> RDEPEND="dev-ruby/stomp
>>         ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>>         ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )"
>>
>> Which, if USE_EXPAND targets were groupped, would go from this
>>   ruby_targets_ruby18? ( dev-lang/ruby:1.8 )
>>   ruby_targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
>>   dep:run? ( dev-ruby/stomp )"
>>
>> to this:
>>   ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
>>   ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
>>   :run? ( dev-ruby/stomp )
>
> Ok, now I get it. I've read the other threads as well, but failed to put it
> all together. Happens when you barely sleep every night :-)
>
> I don't like this mix of dependency types and use flag deps. It smells
> trouble. Dependency types should be easy to separate and read, but the above
> example is a mess, "dep:" or no "dep:".
>
> Why? Because you have to scan the whole thing to sort out which lines are
> dependency types and which lines are use deps and even then it would be easy
> to misread something.
>
> If we want to stay away from labels (which aren't that bad IMO), I'd
> recommend the following instead:
>
> Force explicit setting of the dependency type and disallow the mix of
> dependency types and use flag deps at the same level / block.
>
> DEPENDENCIES="
>   :build,run? ( lib/foo )
>   :run? (
>     lib/bar
>     someuseflag? ( random/app )
>   )
>   :*? (
>     thing? (
>       :build? ( lib/thing )
>       :run? ( lib/thingrunner )
>     )
> "
>
> Or, using your example:
>
> :build,run? (
>
>
>   ruby:targets_ruby18? ( dev-lang/ruby:1.8 )
>   ruby:targets_ree18? ( dev-lang/ruby-enterprise:1.8 )
> )
> :run? ( dev-ruby/stomp )
>
> Alex | wired

Or, even easier and more straightforward: just keep using *DEPEND. The
case hasn't been made yet why we need to change that in the first
place.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 369 bytes --]

On Mon, 17 Sep 2012 19:49:12 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> Or, even easier and more straightforward: just keep using *DEPEND. The
> case hasn't been made yet why we need to change that in the first
> place.

We're looking at something like eight *DEPEND variables in EAPI 6, with
considerable overlap between them all.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ben de Groot]

On 17 September 2012 20:41, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 17 Sep 2012 19:49:12 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>> Or, even easier and more straightforward: just keep using *DEPEND. The
>> case hasn't been made yet why we need to change that in the first
>> place.
>
> We're looking at something like eight *DEPEND variables in EAPI 6, with
> considerable overlap between them all.

And like now, in the great majority of cases, only two or three will be used.
The enormous cost of moving to a different system (or the folly of using
two systems in parallel) is not worth the slight benefit of a more cosmetic
handling of the few cases where a few more *DEPEND variables would be
needed and/or there is some overlap to be dealt with.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 738 bytes --]

On Mon, 17 Sep 2012 21:48:07 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> On 17 September 2012 20:41, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > On Mon, 17 Sep 2012 19:49:12 +0800
> > Ben de Groot <yngwin@gentoo.org> wrote:
> >> Or, even easier and more straightforward: just keep using *DEPEND.
> >> The case hasn't been made yet why we need to change that in the
> >> first place.
> >
> > We're looking at something like eight *DEPEND variables in EAPI 6,
> > with considerable overlap between them all.
> 
> And like now, in the great majority of cases, only two or three will
> be used. 

And even now, people are using COMMON_DEPEND to work around *DEPEND
duplication.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ben de Groot]

On 17 September 2012 21:58, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 17 Sep 2012 21:48:07 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>> On 17 September 2012 20:41, Ciaran McCreesh
>> <ciaran.mccreesh@googlemail.com> wrote:
>> > On Mon, 17 Sep 2012 19:49:12 +0800
>> > Ben de Groot <yngwin@gentoo.org> wrote:
>> >> Or, even easier and more straightforward: just keep using *DEPEND.
>> >> The case hasn't been made yet why we need to change that in the
>> >> first place.
>> >
>> > We're looking at something like eight *DEPEND variables in EAPI 6,
>> > with considerable overlap between them all.
>>
>> And like now, in the great majority of cases, only two or three will
>> be used.
>
> And even now, people are using COMMON_DEPEND to work around *DEPEND
> duplication.

Yes, and that works just fine. I don't see what's wrong with that...

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 361 bytes --]

On Mon, 17 Sep 2012 22:11:59 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> > And even now, people are using COMMON_DEPEND to work around *DEPEND
> > duplication.
> 
> Yes, and that works just fine. I don't see what's wrong with that...

Well perhaps you should read Brian's lengthy explanation that started
this thread, then.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ben de Groot]

On 17 September 2012 22:14, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> On Mon, 17 Sep 2012 22:11:59 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>> > And even now, people are using COMMON_DEPEND to work around *DEPEND
>> > duplication.
>>
>> Yes, and that works just fine. I don't see what's wrong with that...
>
> Well perhaps you should read Brian's lengthy explanation that started
> this thread, then.

If you mean the email that started this thread, that was neither
lengthy nor explanatory. If you mean the GLEP, that is indeed lengthy,
but mostly goes into the mechanism. It doesn't go into the rationale
to any degree of satisfaction. It doesn't make at all clear why the
supposed benefits would outweigh the costs of such a big change.

If I missed any such explanation among the myriad of related threads,
then please be so kind to link to it.
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michael Mol]

On Mon, Sep 17, 2012 at 9:48 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 17 September 2012 20:41, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
>> On Mon, 17 Sep 2012 19:49:12 +0800
>> Ben de Groot <yngwin@gentoo.org> wrote:
>>> Or, even easier and more straightforward: just keep using *DEPEND. The
>>> case hasn't been made yet why we need to change that in the first
>>> place.
>>
>> We're looking at something like eight *DEPEND variables in EAPI 6, with
>> considerable overlap between them all.
>
> And like now, in the great majority of cases, only two or three will be used.
> The enormous cost of moving to a different system (or the folly of using
> two systems in parallel) is not worth the slight benefit of a more cosmetic
> handling of the few cases where a few more *DEPEND variables would be
> needed and/or there is some overlap to be dealt with.

As someone who's been reading these threads, but hasn't actually
written any ebuilds from scratch, I'd like to offer my perspective as
a well-intentioned beginner:

On labels: The labels, to me, appeared largely more readable (and less
formidable a syntax to read and write as a human) than the foo? (
bar/baz ) syntax...until someone demonstrated a distinction between
depends and dependency types. I hadn't even noticed a distinction
between the two, until that point was raised.

While I like the labels (to me, they feel similar to Makefiles or C
switch statements), a clearer distinction between dependencies and
dependency types would be nice.

On unified DEPENDS vs *DEPEND: It seems to me that at a code level,
there's no real semantic difference. Since they both parse out
losslessly to the same abstract thing, you could serialize that
abstract thing back out into either format. Given most cases will be
simple, you could even serialize it away into something not
bash-based, if desired. All this means, to me, that the behavior of
the two under the hood is essentially irrelevant, and any bugs in
complex implementation could be caught with automated testing.

I personally favor a singular 'DEPENDS', because

1) I feel it would lead to better-organized documentation (I'm looking
for details about one var, rather than two or three vars--oh and then
there's the other N *DEPENDS I may not even have heard of yet), and

2) I worry less about accidental namespace pollution in my make.conf
file. Why do I worry about namespace pollution? Rather than using
profiles, I have around 40-50 USE flags divided by category into
varnames like SYS_USE_COMPRESION, and then I have a line that says
USE="${SYS_USE_CPU} ${SYS_USE_COMPRESSION} ${SYS_USE_DONOTWANT} # etc"
which coalesces it all. When I ran into a strange problem some time
back, someone assisting me initially suspected that my SYS_USE_* vars
might be conflicting with something internal to portage.

Again, this isn't coming from a seasoned developer, this is coming
from a well-intentioned beginner with very little time on his hands.
-- 
:wq

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 17/09/12 07:49 AM, Ben de Groot wrote:

>> Or, using your example:
>> 
>> :build,run? (
>> 
>> 
>> ruby:targets_ruby18? ( dev-lang/ruby:1.8 ) ruby:targets_ree18? (
>> dev-lang/ruby-enterprise:1.8 ) ) :run? ( dev-ruby/stomp )
>> 

Just a minor point of clarification -- wouldn't technically the
proposed USE_EXPAND syntax be:


:build,run? (
   ruby_targets:ruby18? ( dev-lang/ruby:1.8 )
   ruby_targets:ree18? ( dev-lang/ruby-enterprise:1.8 )
)

...??  (ie, the prefix is the entire USE_EXPAND string)?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBYaEAACgkQ2ugaI38ACPCowAD/Rma+GlIkZhfMcydNjIEcGFdn
a3HbJTr7UWa696H1ahEA+wdI4mwNX+q1pG6kk8n/I4PVnHNtMSHw9h/Oq7QgkKpM
=YTz/
-----END PGP SIGNATURE-----

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 2141 bytes --]

On Sun, 2012-09-16 at 06:52 -0700, Brian Harring wrote:
> Folks-
> 
> Keeping it short and quick, a basic glep has been written for what I'm 
> proposing for DEPENDENCIES enhancement.
> 
> The live version of the doc is available at 
> http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html 
> 
> Wording fixes will occur, but the core concept shouldn't change (and 
> if it does, per PEP standards, the changes will be noted/tracked).
> 
> Please have a read through; it should be clear/concise as to why PM 
> authors are pushing for a unified dependencies to be done, what we can 
> get from it now, what it enables moving forward, and the direct cost 
> to devs should this idea be implemented.
> 
> Just to be absolutely clear, what I'm proposing is basically zero cost 
> for devs- they can (and should when it's in their benefit) switch to 
> the new syntax when it makes their job easier; it can be used in 
> parallel to existing DEPEND/RDEPEND/PDEPEND both to ease 
> transition/compatibility.
> 
> In addition, a prototype portage patch has been cut for dependencies 
> support (needs work/full validation), and a matching pkgcore one has 
> been cut.
> 
> I realize it's a complex subject; if you have questions, please feel 
> to ask.
> 
> Thanks, and pardon the ancillary/daft noise that has gone with this 
> subject.
> 
> ~harring
> 

I like the idea of a unified DEPENDENCIES.  Potential flame wars aside,
I also like the extended USE flag syntax approach.  While it would be
nice to loose the repetitive "dep:" portion, I can understand the
importance of maintaining a namespace ID to prevent it from being
injected where it does not belong.  It adds to the consistency of the
USE flag syntax while condensing the results.  Reducing the size will
help speed things along as well as reduce resource overhead (rsyncing
the tree).

I think it will be a good step forward in the evolution of gentoo.

I would also put forth effort to help with tools to help devs migrate
and check correctness before committing.
-- 
Brian Dolbec <dolsen@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Arfrever Frehtes Taifersar Arahesis]

[-- Attachment #1: Type: Text/Plain, Size: 375 bytes --]

A potential dev-libs/dep package might have valid use case for USE flags related to USE_EXPAND="DEP".
Your suggested syntax for types of dependencies in DEPENDENCIES would conflict with these USE flags
after implementing ":" delimiter for USE_EXPAND-related USE flags.

I vote for a separate syntax for types of dependencies.

-- 
Arfrever Frehtes Taifersar Arahesis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Tue, Sep 18, 2012 at 06:04:51AM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
> A potential dev-libs/dep package

I assume this is a hypothetical package; if this is something out of 
your personal eapi/repo, please state so.

> might have valid use case for USE flags related to USE_EXPAND="DEP".
> Your suggested syntax for types of dependencies in DEPENDENCIES would conflict with these USE flags
> after implementing ":" delimiter for USE_EXPAND-related USE flags.

Actually, that was both the intent, and I thought explicitly 
clear/documented; 'dep' would be a PM controlled namespace- as I'm 
pretty sure I stated in the doc, else in that email thread on the 
subject.

Thus, yep, you got me, you can't create a USE_EXPAND/USE_GROUP named 
'dep'.

I very, very strongly doubt that anyone ever would come up with a 
scenario where this is required, and the alternative name is somehow 
worse.  Please give examples.

Also, you should keep in mind that w/ what I ultimately want for 
USE_EXPAND, we'd have a couple other namespace that couldn't be used 
by ebuilds/profiles.

Top of the head,

* arch; kind of a given, alternate addressing of x86 via arch:x86.  
Would be added purely for consistency, although iteration of the 
potential values would warrant the group existing.

* use; same reasoning as arch, added for consistency so the consuming 
code doesn't have to special case things.

* phase; intentionally reserved should we ever decide to do per phase 
restrict control (aka, turning userpriv off just for the test phase).

* license; Now, this one I *am* spitballing a bit- I'm not proposing 
it, just frankly thinking out loud.  If we had a license namespace 
there, we could potentially mask out certain deps if the user 
requested say pure bsd, or as a potential way to properly integrate in 
our existing bindist support; keep in mind if the group existed, we 
could use it in REQUIRED_USE also.


Either way, you get the idea; it was explicit that in fixing 
use_expand, a few namespaces would be offlimits.


> I vote for a separate syntax for types of dependencies.

A separate syntax, or keeping dep:build? from conflicting w/ someone 
wanting to use USE_EXPAND="DEP" ?

If you've got other critiques state them, else, while your opinion is 
yours, I doubt anyone is going to agree with you that it's a deal 
breaker.

~harring

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[hasufell]

I am unsure if that does or could solve the problem why GLEP 62 was
created, meaning... would enabling the "foo" useflag after the package
has been emerged trigger a remerge in the following example?

DEPENDENCIES="
	dep:run? (
		foo? ( dev-libs/foobar )
	)"

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Tue, Sep 18, 2012 at 08:48:16AM +0200, hasufell wrote:
> I am unsure if that does or could solve the problem why GLEP 62 was
> created, meaning... would enabling the "foo" useflag after the package
> has been emerged trigger a remerge in the following example?
> 
> DEPENDENCIES="
> 	dep:run? (
> 		foo? ( dev-libs/foobar )
> 	)"

Just transfering over the discussion from IRC, tbh hadn't thought 
about it till you mentioned it since it has some potential flaws 
that aren't necessarily recoverable.

Specifically, what happens if to enable dev-libs/foobar support, 
something has to be done at build time?  Think about a systemd use 
flag, where the script just installs some configuration for systemd; 
that's not toggable.

It's not obvious till you trace the implications through, but w/ 
those issues what you wind up with at that point is trying to 
classify use flags, ala glep62; see the past complete-ass-ripping of 
that proposal for why it doesn't fly.

Just adding another; ebuild devs are completely up shit creek if the 
flag induces a build time effect in one spot, and controls optional 
deps in another section of the dep tree.

If someone sees a way to make that work, have at it, although to be 
clear any such notion I'm intentionally leaving out of my proposal 
since I don't see a way to do it without an explicit dep labeling.

~harring

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 602 bytes --]

> 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?

Also, could you please stop spreading FUD with your examples? A quick
glance shows that what you have expanded there, a fairly reasonable
Gentoo dev will solve using:

RDEPEND="..."
DEPEND="${RDEPEND}
    ..."

So if you really want to show some advantages, please compare it with
*real* code.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

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.


> Also, could you please stop spreading FUD with your examples?

It's not FUD; it's rendered deps, and a demonstration of how they 
collapse down naturally on their own regardless of how you generate 
them.

Quite frankly, it's a fairly effective demonstration in my views, but 
so it goes.

> 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 )"
"""

Suspect I may add that to the doc; it's a good example of the ground 
level simple gains for devs inherent in the proposal- thanks for 
helping improve it.


> So if you really want to show some advantages, please compare it with
> *real* code.

I think I'll take the risk, and assume people capable of discussing 
DEPENDENCIES and vaguely knowledgable in the ebuild format will be 
able to understand how their ebuilds will change; thus I'll skip that 
request of yours.


A productive suggestion for you; you should go looking through the 
tree finding cases where DEPENENCIES is a regression in form at the 
shell level, or rendered deps level.

Should you manage to find something that's not contrived or 
intentionally cracktastic, I expect people would be interested.

~harring

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ulrich Mueller]

>>>>> On Tue, 18 Sep 2012, Brian Harring wrote:

> On Tue, Sep 18, 2012 at 10:25:51AM +0200, Micha?? G??rny wrote:
>> Also, could you please stop spreading FUD with your examples?

> It's not FUD; it's rendered deps, and a demonstration of how they 
> collapse down naturally on their own regardless of how you generate 
> them.

> Quite frankly, it's a fairly effective demonstration in my views, but 
> so it goes.

>> 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 )"
> """

Which is longer than the original. ;-)

Ulrich

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[vivo75]

Il 18/09/2012 11:38, Ulrich Mueller ha scritto:
> Which is longer than the original.;-)
>
> Ulrich
RDEPEND=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 app-arch/xz-utils" 
DEPEND="${RDEPEND} virtual/pkgconfig"
DEPENDENCIES=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 
app-arch/xz-utils" dep:build?(virtual/pkgconfig)"

is DEPENDENCIES "the original"?

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ulrich Mueller]

>>>>> On Tue, 18 Sep 2012, vivo75@gmail com wrote:

> Il 18/09/2012 11:38, Ulrich Mueller ha scritto:
>> Which is longer than the original.;-)

> RDEPEND=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 app-arch/xz-utils" 
> DEPEND="${RDEPEND} virtual/pkgconfig"
> DEPENDENCIES=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 
> app-arch/xz-utils" dep:build?(virtual/pkgconfig)"

Omitting the whitespace around the parentheses? This isn't legal
syntax for a dependency specification:
<http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-780009.2>

Neither does it improve readability.

Brian's claim was that dependencies would "collapse down naturally on
their own", which isn't the case in his example.

Ulrich

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Zac Medico]

On 09/18/2012 03:35 AM, Ulrich Mueller wrote:
>>>>>> On Tue, 18 Sep 2012, vivo75@gmail com wrote:
> 
>> Il 18/09/2012 11:38, Ulrich Mueller ha scritto:
>>> Which is longer than the original.;-)
> 
>> RDEPEND=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 app-arch/xz-utils" 
>> DEPEND="${RDEPEND} virtual/pkgconfig"
>> DEPENDENCIES=">=sys-libs/zlib-1.1.4 >=app-arch/bzip2-1.0.2 
>> app-arch/xz-utils" dep:build?(virtual/pkgconfig)"
> 
> Omitting the whitespace around the parentheses? This isn't legal
> syntax for a dependency specification:
> <http://dev.gentoo.org/~ulm/pms/4/pms.html#x1-780009.2>
> 
> Neither does it improve readability.
> 
> Brian's claim was that dependencies would "collapse down naturally on
> their own", which isn't the case in his example.

Also, if we change the meaning of RDEPEND in the next EAPI, so that it's
a hard build-time dep like DEPEND, then DEPEND="${RDEPEND}
virtual/pkgconfig" can be reduced to DEPEND="virtual/pkgconfig". This is
what I would like to do for the experimental EAPI 5-hdepend which is
planned [1].

[1] https://bugs.gentoo.org/show_bug.cgi?id=317337#c120
-- 
Thanks,
Zac

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 540 bytes --]

On Tue, 18 Sep 2012 12:25:57 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> Also, if we change the meaning of RDEPEND in the next EAPI, so that
> it's a hard build-time dep like DEPEND, then DEPEND="${RDEPEND}
> virtual/pkgconfig" can be reduced to DEPEND="virtual/pkgconfig". This
> is what I would like to do for the experimental EAPI 5-hdepend which
> is planned [1].

What're we going to do about the zillions of unsolvable cycles that
that would create? (Does Portage detect those and error out yet?)

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Zac Medico]

On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> On Tue, 18 Sep 2012 12:25:57 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> Also, if we change the meaning of RDEPEND in the next EAPI, so that
>> it's a hard build-time dep like DEPEND, then DEPEND="${RDEPEND}
>> virtual/pkgconfig" can be reduced to DEPEND="virtual/pkgconfig". This
>> is what I would like to do for the experimental EAPI 5-hdepend which
>> is planned [1].
> 
> What're we going to do about the zillions of unsolvable cycles that
> that would create? (Does Portage detect those and error out yet?)

Yeah, it would be treated just like a DEPEND cycle, which is already
detected and treated as a fatal error. As a result, when bumping the
EAPI of an ebuild, you may have to migrate some deps from RDEPEND to
PDEPEND in order to solve the cycles.
-- 
Thanks,
Zac

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]

On Tue, 18 Sep 2012 12:40:51 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> > On Tue, 18 Sep 2012 12:25:57 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> >> Also, if we change the meaning of RDEPEND in the next EAPI, so that
> >> it's a hard build-time dep like DEPEND, then DEPEND="${RDEPEND}
> >> virtual/pkgconfig" can be reduced to DEPEND="virtual/pkgconfig".
> >> This is what I would like to do for the experimental EAPI
> >> 5-hdepend which is planned [1].
> > 
> > What're we going to do about the zillions of unsolvable cycles that
> > that would create? (Does Portage detect those and error out yet?)
> 
> Yeah, it would be treated just like a DEPEND cycle, which is already
> detected and treated as a fatal error. As a result, when bumping the
> EAPI of an ebuild, you may have to migrate some deps from RDEPEND to
> PDEPEND in order to solve the cycles.

What about the large number of RDEPENDs that are required for a package
to be usable, but not for it to be installed?

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Zac Medico]

On 09/18/2012 12:44 PM, Ciaran McCreesh wrote:
> On Tue, 18 Sep 2012 12:40:51 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
>>> On Tue, 18 Sep 2012 12:25:57 -0700
>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>> Also, if we change the meaning of RDEPEND in the next EAPI, so that
>>>> it's a hard build-time dep like DEPEND, then DEPEND="${RDEPEND}
>>>> virtual/pkgconfig" can be reduced to DEPEND="virtual/pkgconfig".
>>>> This is what I would like to do for the experimental EAPI
>>>> 5-hdepend which is planned [1].
>>>
>>> What're we going to do about the zillions of unsolvable cycles that
>>> that would create? (Does Portage detect those and error out yet?)
>>
>> Yeah, it would be treated just like a DEPEND cycle, which is already
>> detected and treated as a fatal error. As a result, when bumping the
>> EAPI of an ebuild, you may have to migrate some deps from RDEPEND to
>> PDEPEND in order to solve the cycles.
> 
> What about the large number of RDEPENDs that are required for a package
> to be usable, but not for it to be installed?

You will have to migrate those deps from RDEPEND to PDEPEND.
-- 
Thanks,
Zac

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]

On Tue, 18 Sep 2012 12:58:30 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> On 09/18/2012 12:44 PM, Ciaran McCreesh wrote:
> > On Tue, 18 Sep 2012 12:40:51 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> >> On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> >>> On Tue, 18 Sep 2012 12:25:57 -0700
> >>> Zac Medico <zmedico@gentoo.org> wrote:
> >>>> Also, if we change the meaning of RDEPEND in the next EAPI, so
> >>>> that it's a hard build-time dep like DEPEND, then
> >>>> DEPEND="${RDEPEND} virtual/pkgconfig" can be reduced to
> >>>> DEPEND="virtual/pkgconfig". This is what I would like to do for
> >>>> the experimental EAPI 5-hdepend which is planned [1].
> >>>
> >>> What're we going to do about the zillions of unsolvable cycles
> >>> that that would create? (Does Portage detect those and error out
> >>> yet?)
> >>
> >> Yeah, it would be treated just like a DEPEND cycle, which is
> >> already detected and treated as a fatal error. As a result, when
> >> bumping the EAPI of an ebuild, you may have to migrate some deps
> >> from RDEPEND to PDEPEND in order to solve the cycles.
> > 
> > What about the large number of RDEPENDs that are required for a
> > package to be usable, but not for it to be installed?
> 
> You will have to migrate those deps from RDEPEND to PDEPEND.

...but PDEPENDs aren't guaranteed to be installed before a package is
used to satisfy a dependency. (And we can't change PDEPEND to do what
RDEPEND currently does, because then some cycles can't be solved at
all.)

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Zac Medico]

On 09/18/2012 01:10 PM, Ciaran McCreesh wrote:
> On Tue, 18 Sep 2012 12:58:30 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> On 09/18/2012 12:44 PM, Ciaran McCreesh wrote:
>>> On Tue, 18 Sep 2012 12:40:51 -0700
>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>> On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
>>>>> On Tue, 18 Sep 2012 12:25:57 -0700
>>>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>>>> Also, if we change the meaning of RDEPEND in the next EAPI, so
>>>>>> that it's a hard build-time dep like DEPEND, then
>>>>>> DEPEND="${RDEPEND} virtual/pkgconfig" can be reduced to
>>>>>> DEPEND="virtual/pkgconfig". This is what I would like to do for
>>>>>> the experimental EAPI 5-hdepend which is planned [1].
>>>>>
>>>>> What're we going to do about the zillions of unsolvable cycles
>>>>> that that would create? (Does Portage detect those and error out
>>>>> yet?)
>>>>
>>>> Yeah, it would be treated just like a DEPEND cycle, which is
>>>> already detected and treated as a fatal error. As a result, when
>>>> bumping the EAPI of an ebuild, you may have to migrate some deps
>>>> from RDEPEND to PDEPEND in order to solve the cycles.
>>>
>>> What about the large number of RDEPENDs that are required for a
>>> package to be usable, but not for it to be installed?
>>
>> You will have to migrate those deps from RDEPEND to PDEPEND.
> 
> ...but PDEPENDs aren't guaranteed to be installed before a package is
> used to satisfy a dependency. (And we can't change PDEPEND to do what
> RDEPEND currently does, because then some cycles can't be solved at
> all.)

Hmm, I think you're probably right. Let's just forget this idea then. :)
-- 
Thanks,
Zac

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

On Tue, 18 Sep 2012 20:44:33 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 12:40:51 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
> > On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> > > On Tue, 18 Sep 2012 12:25:57 -0700
> > > Zac Medico <zmedico@gentoo.org> wrote:
> > >> Also, if we change the meaning of RDEPEND in the next EAPI, so
> > >> that it's a hard build-time dep like DEPEND, then
> > >> DEPEND="${RDEPEND} virtual/pkgconfig" can be reduced to
> > >> DEPEND="virtual/pkgconfig". This is what I would like to do for
> > >> the experimental EAPI 5-hdepend which is planned [1].
> > > 
> > > What're we going to do about the zillions of unsolvable cycles
> > > that that would create? (Does Portage detect those and error out
> > > yet?)
> > 
> > Yeah, it would be treated just like a DEPEND cycle, which is already
> > detected and treated as a fatal error. As a result, when bumping the
> > EAPI of an ebuild, you may have to migrate some deps from RDEPEND to
> > PDEPEND in order to solve the cycles.
> 
> What about the large number of RDEPENDs that are required for a
> package to be usable, but not for it to be installed?

They will still be RDEPEND, just installed earlier I believe. Except
for those arising conflicts which will have to be moved to PDEP. But
I think Zac said that already.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]

On Tue, 18 Sep 2012 22:51:04 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 20:44:33 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 18 Sep 2012 12:40:51 -0700
> > Zac Medico <zmedico@gentoo.org> wrote:
> > > On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> > > > On Tue, 18 Sep 2012 12:25:57 -0700
> > > > Zac Medico <zmedico@gentoo.org> wrote:
> > > >> Also, if we change the meaning of RDEPEND in the next EAPI, so
> > > >> that it's a hard build-time dep like DEPEND, then
> > > >> DEPEND="${RDEPEND} virtual/pkgconfig" can be reduced to
> > > >> DEPEND="virtual/pkgconfig". This is what I would like to do for
> > > >> the experimental EAPI 5-hdepend which is planned [1].
> > > > 
> > > > What're we going to do about the zillions of unsolvable cycles
> > > > that that would create? (Does Portage detect those and error out
> > > > yet?)
> > > 
> > > Yeah, it would be treated just like a DEPEND cycle, which is
> > > already detected and treated as a fatal error. As a result, when
> > > bumping the EAPI of an ebuild, you may have to migrate some deps
> > > from RDEPEND to PDEPEND in order to solve the cycles.
> > 
> > What about the large number of RDEPENDs that are required for a
> > package to be usable, but not for it to be installed?
> 
> They will still be RDEPEND, just installed earlier I believe. Except
> for those arising conflicts which will have to be moved to PDEP. But
> I think Zac said that already.

...but you can't move them to be a PDEPEND, since PDEPENDs aren't
guaranteed to be installed when a package is used.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

On Tue, 18 Sep 2012 21:53:55 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 22:51:04 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 18 Sep 2012 20:44:33 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Tue, 18 Sep 2012 12:40:51 -0700
> > > Zac Medico <zmedico@gentoo.org> wrote:
> > > > On 09/18/2012 12:29 PM, Ciaran McCreesh wrote:
> > > > > On Tue, 18 Sep 2012 12:25:57 -0700
> > > > > Zac Medico <zmedico@gentoo.org> wrote:
> > > > >> Also, if we change the meaning of RDEPEND in the next EAPI,
> > > > >> so that it's a hard build-time dep like DEPEND, then
> > > > >> DEPEND="${RDEPEND} virtual/pkgconfig" can be reduced to
> > > > >> DEPEND="virtual/pkgconfig". This is what I would like to do
> > > > >> for the experimental EAPI 5-hdepend which is planned [1].
> > > > > 
> > > > > What're we going to do about the zillions of unsolvable cycles
> > > > > that that would create? (Does Portage detect those and error
> > > > > out yet?)
> > > > 
> > > > Yeah, it would be treated just like a DEPEND cycle, which is
> > > > already detected and treated as a fatal error. As a result, when
> > > > bumping the EAPI of an ebuild, you may have to migrate some deps
> > > > from RDEPEND to PDEPEND in order to solve the cycles.
> > > 
> > > What about the large number of RDEPENDs that are required for a
> > > package to be usable, but not for it to be installed?
> > 
> > They will still be RDEPEND, just installed earlier I believe. Except
> > for those arising conflicts which will have to be moved to PDEP. But
> > I think Zac said that already.
> 
> ...but you can't move them to be a PDEPEND, since PDEPENDs aren't
> guaranteed to be installed when a package is used.

But didn't we already point out that we can't have them in RDEPEND
since they introduce conflicts?

Unless you're talking about that group of dependencies which doesn't
introduce conflicts in RDEPEND now but will introduce them after
the change. We should probably do some kind of tree-wide study on how
large the problem is.

A simple solution would be to mandate installing PDEPs as soon
as possible. In case of those dependencies, that would mean installing
them like RDEPENDs are installed now, wouldn't it?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 354 bytes --]

On Tue, 18 Sep 2012 23:06:06 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> But didn't we already point out that we can't have them in RDEPEND
> since they introduce conflicts?

You are missing a basic and important part of how dependency resolution
works: currently, cycles consisting purely of RDEPENDs are ignorable.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 607 bytes --]

On Tue, 18 Sep 2012 22:08:43 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 23:06:06 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > But didn't we already point out that we can't have them in RDEPEND
> > since they introduce conflicts?
> 
> You are missing a basic and important part of how dependency
> resolution works: currently, cycles consisting purely of RDEPENDs are
> ignorable.

So, what do we lose? If PDEP comes 'ASAP' officially, I believe that we
actually gain RDEPs which can be actually trusted.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 924 bytes --]

On Tue, 18 Sep 2012 23:34:29 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 22:08:43 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 18 Sep 2012 23:06:06 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > But didn't we already point out that we can't have them in RDEPEND
> > > since they introduce conflicts?
> > 
> > You are missing a basic and important part of how dependency
> > resolution works: currently, cycles consisting purely of RDEPENDs
> > are ignorable.
> 
> So, what do we lose? If PDEP comes 'ASAP' officially, I believe that
> we actually gain RDEPs which can be actually trusted.

"ASAP" is a weaker guarantee that RDEPENDs currently have -- RDEPENDs
currently have the weakest guarantee necessary to ensure that they can
be trusted. It's also a useless guarantee, since "ASAP" can be
arbitrarily late.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

On Tue, 18 Sep 2012 22:37:19 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 23:34:29 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 18 Sep 2012 22:08:43 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Tue, 18 Sep 2012 23:06:06 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > But didn't we already point out that we can't have them in
> > > > RDEPEND since they introduce conflicts?
> > > 
> > > You are missing a basic and important part of how dependency
> > > resolution works: currently, cycles consisting purely of RDEPENDs
> > > are ignorable.
> > 
> > So, what do we lose? If PDEP comes 'ASAP' officially, I believe that
> > we actually gain RDEPs which can be actually trusted.
> 
> "ASAP" is a weaker guarantee that RDEPENDs currently have -- RDEPENDs
> currently have the weakest guarantee necessary to ensure that they can
> be trusted. It's also a useless guarantee, since "ASAP" can be
> arbitrarily late.

And can't RDEPENDs be arbitrarily late if there is a cycle?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1389 bytes --]

On Wed, 19 Sep 2012 00:01:21 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 22:37:19 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 18 Sep 2012 23:34:29 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > On Tue, 18 Sep 2012 22:08:43 +0100
> > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > On Tue, 18 Sep 2012 23:06:06 +0200
> > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > But didn't we already point out that we can't have them in
> > > > > RDEPEND since they introduce conflicts?
> > > > 
> > > > You are missing a basic and important part of how dependency
> > > > resolution works: currently, cycles consisting purely of
> > > > RDEPENDs are ignorable.
> > > 
> > > So, what do we lose? If PDEP comes 'ASAP' officially, I believe
> > > that we actually gain RDEPs which can be actually trusted.
> > 
> > "ASAP" is a weaker guarantee that RDEPENDs currently have --
> > RDEPENDs currently have the weakest guarantee necessary to ensure
> > that they can be trusted. It's also a useless guarantee, since
> > "ASAP" can be arbitrarily late.
> 
> And can't RDEPENDs be arbitrarily late if there is a cycle?

No. RDEPENDs have to be available when a package is used to satisfy a
dependency. That's the difference between an RDEPEND and a PDEPEND.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

On Tue, 18 Sep 2012 23:06:19 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Wed, 19 Sep 2012 00:01:21 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 18 Sep 2012 22:37:19 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Tue, 18 Sep 2012 23:34:29 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > On Tue, 18 Sep 2012 22:08:43 +0100
> > > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > > On Tue, 18 Sep 2012 23:06:06 +0200
> > > > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > > > But didn't we already point out that we can't have them in
> > > > > > RDEPEND since they introduce conflicts?
> > > > > 
> > > > > You are missing a basic and important part of how dependency
> > > > > resolution works: currently, cycles consisting purely of
> > > > > RDEPENDs are ignorable.
> > > > 
> > > > So, what do we lose? If PDEP comes 'ASAP' officially, I believe
> > > > that we actually gain RDEPs which can be actually trusted.
> > > 
> > > "ASAP" is a weaker guarantee that RDEPENDs currently have --
> > > RDEPENDs currently have the weakest guarantee necessary to ensure
> > > that they can be trusted. It's also a useless guarantee, since
> > > "ASAP" can be arbitrarily late.
> > 
> > And can't RDEPENDs be arbitrarily late if there is a cycle?
> 
> No. RDEPENDs have to be available when a package is used to satisfy a
> dependency. That's the difference between an RDEPEND and a PDEPEND.

So, if a particular cycle prohibits RDEPENDs being fulfilled when
RDEPEND is needed to satisfy a dependency, we have a failure now,
correct?

Do we have that guarantee somewhere in the PMS?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Wed, Sep 19, 2012 at 12:53:09AM +0200, Micha?? G??rny wrote:
> On Tue, 18 Sep 2012 23:06:19 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> 
> > On Wed, 19 Sep 2012 00:01:21 +0200
> > Micha?? G??rny <mgorny@gentoo.org> wrote:
> > > On Tue, 18 Sep 2012 22:37:19 +0100
> > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > On Tue, 18 Sep 2012 23:34:29 +0200
> > > > Micha?? G??rny <mgorny@gentoo.org> wrote:
> > > > > On Tue, 18 Sep 2012 22:08:43 +0100
> > > > > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > > > > On Tue, 18 Sep 2012 23:06:06 +0200
> > > > > > Micha?? G??rny <mgorny@gentoo.org> wrote:
> > > > > > > But didn't we already point out that we can't have them in
> > > > > > > RDEPEND since they introduce conflicts?
> > > > > > 
> > > > > > You are missing a basic and important part of how dependency
> > > > > > resolution works: currently, cycles consisting purely of
> > > > > > RDEPENDs are ignorable.
> > > > > 
> > > > > So, what do we lose? If PDEP comes 'ASAP' officially, I believe
> > > > > that we actually gain RDEPs which can be actually trusted.
> > > > 
> > > > "ASAP" is a weaker guarantee that RDEPENDs currently have --
> > > > RDEPENDs currently have the weakest guarantee necessary to ensure
> > > > that they can be trusted. It's also a useless guarantee, since
> > > > "ASAP" can be arbitrarily late.
> > > 
> > > And can't RDEPENDs be arbitrarily late if there is a cycle?
> > 
> > No. RDEPENDs have to be available when a package is used to satisfy a
> > dependency. That's the difference between an RDEPEND and a PDEPEND.
> 
> So, if a particular cycle prohibits RDEPENDs being fulfilled when
> RDEPEND is needed to satisfy a dependency, we have a failure now,
> correct?

Depends on the cycle, but yes.

Order of depdencies for this converation; depends is strongest, 
rdepends is second, pdepend is weak.  If a pkg both deps and rdeps on 
something, for building (since that's the first op), dep obviously 
trumps all other dep forms for that pkg.

pkg1 depends <-> pkg2 depends cycle, we're boned, unsolvable; use dep 
toggling at best.

pkg1 rdepends -> pkg2, pkg2 depends on pkg1, strictly speaking, we're 
boned; pkg1 isn't considered 'usable' until pkg2 is considered 
'usable'.  This is the common case where use pdepend instead of rdep.

pkg1 rdepends <-> pkg2 rdepends; this is a contained cycle, and is 
mergable.

Now if for pkg1 rdep<->pkg2 rdep, pkg2 rdeps on pkg3 (which neds to 
be built), which deps on pkg1 this too, is an unsolvable chain.

you can build pkg1 and pkg2, and even install them.  But pkg3 cannot 
be built until pkg1 is considered 'usable', which can't be be 
considered usable till pkg2 is considered usable, which (take a guess 
where I'm going with this) can't be considered usable until pkg3 is 
considered usable.


> Do we have that guarantee somewhere in the PMS?

It's not too hard to check in the doc yourself, ya know. ;)

relevant latex chunk:
"""
\begin{compactitem}

\item Build dependencies (\t{DEPEND}). These must be installed and 
usable before any of the ebuild \t{src\_*} phase functions is 
executed. These may not be installed at all if a binary package is 
being merged.

\item Runtime dependencies (\t{RDEPEND}). These must be installed and 
usable befor the results of an ebuild merging are treated as usable.

\item Post dependencies (\t{PDEPEND}). These must be installed at some 
point before  the package manager finishes the batch of installs.
\end{compactitem}
"""

keyword there is 'usable'.  Wording could be expanded, but the core 
notion is there- it just skips going over graph theory/resolver 
guts/cycles since they're not explicitly a property of dependecy 
types.

Feel free to write a patch expanding the wording htere...

~harring

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 563 bytes --]

On Tue, 18 Sep 2012 16:28:59 -0700
Brian Harring <ferringb@gmail.com> wrote:

> pkg1 rdepends <-> pkg2 rdepends; this is a contained cycle, and is 
> mergable.

Do you have maybe a quick tool which could find those cycles
in the tree for us?

> keyword there is 'usable'.  Wording could be expanded, but the core 
> notion is there- it just skips going over graph theory/resolver 
> guts/cycles since they're not explicitly a property of dependecy 
> types.

Ah, right, I didn't notice the 'usable' in DEPEND.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Wed, 19 Sep 2012 12:48:00 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 16:28:59 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> > pkg1 rdepends <-> pkg2 rdepends; this is a contained cycle, and is 
> > mergable.
> 
> Do you have maybe a quick tool which could find those cycles
> in the tree for us?

I have a sneaking suspicion that any tool that could do that wouldn't
be quick...

Having said that, if you're after a rough idea of what we're dealing
with, everything in orange deps (either directly or indirectly) upon
everything else in orange:

http://dev.exherbo.org/~ciaranm/resolution-fdp.png

(That's a small part of Gentoo, from a while back, with X not enabled.
It's far worse if X is on too.)

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Tue, Sep 18, 2012 at 11:38:50AM +0200, Ulrich Mueller wrote:
> >>>>> On Tue, 18 Sep 2012, Brian Harring wrote:
> 
> > On Tue, Sep 18, 2012 at 10:25:51AM +0200, Micha?? G??rny wrote:
> >> Also, could you please stop spreading FUD with your examples?
> 
> > It's not FUD; it's rendered deps, and a demonstration of how they 
> > collapse down naturally on their own regardless of how you generate 
> > them.
> 
> > Quite frankly, it's a fairly effective demonstration in my views, but 
> > so it goes.
> 
> >> 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 )"
> > """
> 
> Which is longer than the original. ;-)

I see 5 lines in the first version, and 4 in the second.  I also see 
either someone who counted wrong, or basing that statement purely on 
byte count (which is frankly arguing to argue on your part).

Either way, pretty sure your view is -1; I'll add it into the glep 
along mgorny, skipping sniping like the above.

~harring

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ulrich Mueller]

>>>>> On Tue, 18 Sep 2012, Brian Harring wrote:

>> > 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 )"
>> > """
>> 
>> Which is longer than the original. ;-)

> I see 5 lines in the first version, and 4 in the second.  I also see 
> either someone who counted wrong, or basing that statement purely on 
> byte count (which is frankly arguing to argue on your part).

Can we agree that both counting of lines and characters is silly? ;-)
My point was that the new syntax isn't significantly more compact than
the present one. In one case there is another variable assignment,
in the other case you need an additional "dep:build? (
virtual/pkgconfig )" group.

Readability is more important, and there I still don't buy the
argument that the new syntax is better, and that any gain would
outweigh the cost of changing. After all, the existing variables for
dependency specification won't disappear, so devs would have to
remember both.

Ulrich

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Alec Warner]

On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Tue, 18 Sep 2012, Brian Harring wrote:
>
>>> > 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 )"
>>> > """
>>>
>>> Which is longer than the original. ;-)
>
>> I see 5 lines in the first version, and 4 in the second.  I also see
>> either someone who counted wrong, or basing that statement purely on
>> byte count (which is frankly arguing to argue on your part).
>
> Can we agree that both counting of lines and characters is silly? ;-)
> My point was that the new syntax isn't significantly more compact than
> the present one. In one case there is another variable assignment,
> in the other case you need an additional "dep:build? (
> virtual/pkgconfig )" group.
>
> Readability is more important, and there I still don't buy the
> argument that the new syntax is better, and that any gain would
> outweigh the cost of changing. After all, the existing variables for
> dependency specification won't disappear, so devs would have to
> remember both.

I agree it is a con, but is it a blocker? I mean basically any change
proposed requires know the old way, and the new way..that is how
changes work...

>
> Ulrich
>

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 2131 bytes --]

On Tue, 18 Sep 2012 19:18:31 +0000
Alec Warner <antarus@gentoo.org> wrote:

> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org>
> wrote:
> >>>>>> On Tue, 18 Sep 2012, Brian Harring wrote:
> >
> >>> > 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 )"
> >>> > """
> >>>
> >>> Which is longer than the original. ;-)
> >
> >> I see 5 lines in the first version, and 4 in the second.  I also
> >> see either someone who counted wrong, or basing that statement
> >> purely on byte count (which is frankly arguing to argue on your
> >> part).
> >
> > Can we agree that both counting of lines and characters is
> > silly? ;-) My point was that the new syntax isn't significantly
> > more compact than the present one. In one case there is another
> > variable assignment, in the other case you need an additional
> > "dep:build? ( virtual/pkgconfig )" group.
> >
> > Readability is more important, and there I still don't buy the
> > argument that the new syntax is better, and that any gain would
> > outweigh the cost of changing. After all, the existing variables for
> > dependency specification won't disappear, so devs would have to
> > remember both.
> 
> I agree it is a con, but is it a blocker? I mean basically any change
> proposed requires know the old way, and the new way..that is how
> changes work...

That's why people have to think changes through before making them,
and they have to think whether the benefits outweigh the problems
introduced.

So far, I'm not sure if there was a single, complete, exact problem
discussed which is solved by this syntax other than cosmetics.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

On Tue, 18 Sep 2012 22:06:06 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> So far, I'm not sure if there was a single, complete, exact problem
> discussed which is solved by this syntax other than cosmetics.

Perhaps you should read the GLEP then.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 530 bytes --]

On Tue, 18 Sep 2012 21:11:10 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 22:06:06 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > So far, I'm not sure if there was a single, complete, exact problem
> > discussed which is solved by this syntax other than cosmetics.
> 
> Perhaps you should read the GLEP then.

Thanks for your comprehensive answer. Could you point me, please, where
is there a real, current, exact problem described?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

On Tue, 18 Sep 2012 22:22:56 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 21:11:10 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Tue, 18 Sep 2012 22:06:06 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > So far, I'm not sure if there was a single, complete, exact
> > > problem discussed which is solved by this syntax other than
> > > cosmetics.
> > 
> > Perhaps you should read the GLEP then.
> 
> Thanks for your comprehensive answer. Could you point me, please,
> where is there a real, current, exact problem described?

"Motivation / Rationale"

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 935 bytes --]

On Tue, 18 Sep 2012 21:27:17 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Tue, 18 Sep 2012 22:22:56 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > On Tue, 18 Sep 2012 21:11:10 +0100
> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > > On Tue, 18 Sep 2012 22:06:06 +0200
> > > Michał Górny <mgorny@gentoo.org> wrote:
> > > > So far, I'm not sure if there was a single, complete, exact
> > > > problem discussed which is solved by this syntax other than
> > > > cosmetics.
> > > 
> > > Perhaps you should read the GLEP then.
> > 
> > Thanks for your comprehensive answer. Could you point me, please,
> > where is there a real, current, exact problem described?
> 
> "Motivation / Rationale"

Thanks again, I can read. Now, which one is a problem which currently
exists in Gentoo, is exactly described and is not a cosmetic problem?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ben de Groot]

On 19 September 2012 04:40, Michał Górny <mgorny@gentoo.org> wrote:
> On Tue, 18 Sep 2012 21:27:17 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>
>> On Tue, 18 Sep 2012 22:22:56 +0200
>> Michał Górny <mgorny@gentoo.org> wrote:
>> > On Tue, 18 Sep 2012 21:11:10 +0100
>> > Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
>> > > On Tue, 18 Sep 2012 22:06:06 +0200
>> > > Michał Górny <mgorny@gentoo.org> wrote:
>> > > > So far, I'm not sure if there was a single, complete, exact
>> > > > problem discussed which is solved by this syntax other than
>> > > > cosmetics.
>> > >
>> > > Perhaps you should read the GLEP then.
>> >
>> > Thanks for your comprehensive answer. Could you point me, please,
>> > where is there a real, current, exact problem described?
>>
>> "Motivation / Rationale"
>
> Thanks again, I can read. Now, which one is a problem which currently
> exists in Gentoo, is exactly described and is not a cosmetic problem?

There isn't one in the current GLEP.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 18/09/12 04:11 PM, Ciaran McCreesh wrote:
> On Tue, 18 Sep 2012 22:06:06 +0200 Michał Górny
> <mgorny@gentoo.org> wrote:
>> So far, I'm not sure if there was a single, complete, exact 
>> problem discussed which is solved by this syntax other than 
>> cosmetics.
> 
> Perhaps you should read the GLEP then.
> 

IIRC, there were no *problems* listed in the glep.  There were only a
few things listed that DEPENDENCIES provides advantages over, and a
few things that are (to varying degrees, depending on the dev)
considered to be undesirable.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBY2/kACgkQ2ugaI38ACPCcewD9FzAFNIrkumqyI3dZrkshNStu
t5cqqE5YWYltwJwmW0IA/RQAJk2wtzdXp/4NDvJn3zZ3PJhjFODmonRdWab4u/Q7
=g1Xe
-----END PGP SIGNATURE-----

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ben de Groot]

On 19 September 2012 03:18, Alec Warner <antarus@gentoo.org> wrote:
> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>> Readability is more important, and there I still don't buy the
>> argument that the new syntax is better, and that any gain would
>> outweigh the cost of changing. After all, the existing variables for
>> dependency specification won't disappear, so devs would have to
>> remember both.
>
> I agree it is a con, but is it a blocker? I mean basically any change
> proposed requires know the old way, and the new way..that is how
> changes work...

Which is why changes need to have clear benefits that outweigh the
costs of change. In this case the benefits are purely cosmetic, so
they don't. Change for change' sake is not worth the effort.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Matt Turner]

 On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 19 September 2012 03:18, Alec Warner <antarus@gentoo.org> wrote:
>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>> Readability is more important, and there I still don't buy the
>>> argument that the new syntax is better, and that any gain would
>>> outweigh the cost of changing. After all, the existing variables for
>>> dependency specification won't disappear, so devs would have to
>>> remember both.
>>
>> I agree it is a con, but is it a blocker? I mean basically any change
>> proposed requires know the old way, and the new way..that is how
>> changes work...
>
> Which is why changes need to have clear benefits that outweigh the
> costs of change. In this case the benefits are purely cosmetic, so
> they don't. Change for change' sake is not worth the effort.
>
> --
> Cheers,
>
> Ben | yngwin
> Gentoo developer
> Gentoo Qt project lead, Gentoo Wiki admin
>

I'm sorry. Are you reading the same threads that I am?

From the other thread ("example conversion of gentoo-x86 current deps
to unified dependencies"):

> 1) This unifies the existing syntax down into a collapsed form.  In
> doing so, there are measurable gains across the board for PM
> efficiency and rsync alone.
>
> 2) In unifying the syntax via reusing our /existing fucking syntax/,
> we formalize the adhoc common dependency assignments devs already are
> doing in the tree.
>
> 3) In moving to a unified syntax, it positions us to easily introduce
> new dependency types without introducing more redundancy.  Easier to
> add new dep types, faster to add new dep types, more efficient in
> doing so in comparison to existing approaches, and done in a fashion
> that devs can reuse existing conditionals.
>
> 4) It is not exherbo's DEPENDENCIES.  Meaning it is not label based.
> Meaning you do not need to knee-jerk attack it because of some notion
> it's ciaran based/related.

I know you must have seen this (and the rest...). You've participated
in that thread.

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ulrich Mueller]

>>>>> On Tue, 18 Sep 2012, Matt Turner wrote:

> From the other thread ("example conversion of gentoo-x86 current
> deps to unified dependencies"):

[Sorry, I've missed this one in the other thread, so replying here.]

>> 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based.
>> Meaning you do not need to knee-jerk attack it because of some
>> notion it's ciaran based/related.

What kind of reasoning is this? Does it mean that the syntax was
deliberately changed to make it different from exherbo's?

We should accept (or reject) things based on their technical merits,
not because of ad-hominem or "not invented here" arguments.

Ulrich

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Matt Turner]

On Tue, Sep 18, 2012 at 11:36 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Tue, 18 Sep 2012, Matt Turner wrote:
>
>> From the other thread ("example conversion of gentoo-x86 current
>> deps to unified dependencies"):
>
> [Sorry, I've missed this one in the other thread, so replying here.]
>
>>> 4) It is not exherbo's DEPENDENCIES. Meaning it is not label based.
>>> Meaning you do not need to knee-jerk attack it because of some
>>> notion it's ciaran based/related.
>
> What kind of reasoning is this? Does it mean that the syntax was
> deliberately changed to make it different from exherbo's?
>
> We should accept (or reject) things based on their technical merits,
> not because of ad-hominem or "not invented here" arguments.
>
> Ulrich
>

Brian was mocking how so many people reject anything Ciaran proposes
out of hand. He actually discussed the reasoning why he doesn't
actually like labels in another thread.

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Ben de Groot]

On 19 September 2012 14:01, Matt Turner <mattst88@gentoo.org> wrote:
>  On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>> On 19 September 2012 03:18, Alec Warner <antarus@gentoo.org> wrote:
>>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>> Readability is more important, and there I still don't buy the
>>>> argument that the new syntax is better, and that any gain would
>>>> outweigh the cost of changing. After all, the existing variables for
>>>> dependency specification won't disappear, so devs would have to
>>>> remember both.
>>>
>>> I agree it is a con, but is it a blocker? I mean basically any change
>>> proposed requires know the old way, and the new way..that is how
>>> changes work...
>>
>> Which is why changes need to have clear benefits that outweigh the
>> costs of change. In this case the benefits are purely cosmetic, so
>> they don't. Change for change' sake is not worth the effort.
>>
>> --
>> Cheers,
>>
>> Ben | yngwin
>> Gentoo developer
>> Gentoo Qt project lead, Gentoo Wiki admin
>>
>
> I'm sorry. Are you reading the same threads that I am?

You've seen me participating in those, so obviously: yes.

> From the other thread ("example conversion of gentoo-x86 current deps
> to unified dependencies"):
>
>> 1) This unifies the existing syntax down into a collapsed form.  In
>> doing so, there are measurable gains across the board for PM
>> efficiency and rsync alone.

Unifying existing syntax = cosmetic

If collapsing it is beneficial for PM internals, please do so
internally while hiding it from ebuild devs.

>> 2) In unifying the syntax via reusing our /existing fucking syntax/,
>> we formalize the adhoc common dependency assignments devs already are
>> doing in the tree.

Again, cosmetic

>> 3) In moving to a unified syntax, it positions us to easily introduce
>> new dependency types without introducing more redundancy.  Easier to
>> add new dep types, faster to add new dep types, more efficient in
>> doing so in comparison to existing approaches, and done in a fashion
>> that devs can reuse existing conditionals.

Again, cosmetic

Note that adding new dep types only comes up very rarely.

>> 4) It is not exherbo's DEPENDENCIES.  Meaning it is not label based.
>> Meaning you do not need to knee-jerk attack it because of some notion
>> it's ciaran based/related.

Hm, yeah, so?

> I know you must have seen this (and the rest...). You've participated
> in that thread.

Indeed. So what made you wonder if I had seen that?

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Jeroen Roovers]

On Wed, 19 Sep 2012 15:12:42 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> >> 1) This unifies the existing syntax down into a collapsed form.  In
> >> doing so, there are measurable gains across the board for PM
> >> efficiency and rsync alone.
> 
> Unifying existing syntax = cosmetic

Not *entirely* cosmetic. If only you should have seen the scores of bug
reports that got resolved by simply switching DEPEND and RDEPEND in an
ebuild. Apparently a single character difference is often easy to
miss, (perhaps especially in dealing with uppercase variables). It is
definitely easier to spot the difference between lowercase "build" and
"run", so even a cosmetic change could be beneficial if it enhanced
legibility, right?


     jer

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Matt Turner]

On Wed, Sep 19, 2012 at 12:12 AM, Ben de Groot <yngwin@gentoo.org> wrote:
> On 19 September 2012 14:01, Matt Turner <mattst88@gentoo.org> wrote:
>>  On Tue, Sep 18, 2012 at 9:07 PM, Ben de Groot <yngwin@gentoo.org> wrote:
>>> On 19 September 2012 03:18, Alec Warner <antarus@gentoo.org> wrote:
>>>> On Tue, Sep 18, 2012 at 12:11 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>> Readability is more important, and there I still don't buy the
>>>>> argument that the new syntax is better, and that any gain would
>>>>> outweigh the cost of changing. After all, the existing variables for
>>>>> dependency specification won't disappear, so devs would have to
>>>>> remember both.
>>>>
>>>> I agree it is a con, but is it a blocker? I mean basically any change
>>>> proposed requires know the old way, and the new way..that is how
>>>> changes work...
>>>
>>> Which is why changes need to have clear benefits that outweigh the
>>> costs of change. In this case the benefits are purely cosmetic, so
>>> they don't. Change for change' sake is not worth the effort.
>>>
>>> --
>>> Cheers,
>>>
>>> Ben | yngwin
>>> Gentoo developer
>>> Gentoo Qt project lead, Gentoo Wiki admin
>>>
>>
>> I'm sorry. Are you reading the same threads that I am?
>
> You've seen me participating in those, so obviously: yes.

So then you must have also read Brian's email detailing the metadata
savings, and allowing the PM to parse fewer things (even with
quantitative measurements!). Search your email for 'cold cache'.

[snip]

Looking at what you call cosmetic makes me think that you're
collapsing "cosmetic and a useful change" down into "cosmetic" in
order to disregard it.

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1722 bytes --]

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.

> > 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?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposas

[Brian Harring]

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

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Hans de Graaff]

On Tue, 2012-09-18 at 11:47 +0200, Michał Górny wrote:

> 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.

It would enable us to consider making tests on some packages optional to
break circular dependencies with FEATURES=test, i.e. only run the tests
if the test dependencies can be installed without circular dependencies.

https://bugs.gentoo.org/show_bug.cgi?id=175808

Hans

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michael Mol]

On Tue, Sep 18, 2012 at 1:07 PM, Hans de Graaff <graaff@gentoo.org> wrote:
> On Tue, 2012-09-18 at 11:47 +0200, Michał Górny wrote:
>
>> 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.
>
> It would enable us to consider making tests on some packages optional to
> break circular dependencies with FEATURES=test, i.e. only run the tests
> if the test dependencies can be installed without circular dependencies.
>
> https://bugs.gentoo.org/show_bug.cgi?id=175808

Thought: That might also allow you to split an emerge into two
separate jobs. I.e. "it's inconvenient, difficult or impossible to
have test dependencies installed at build time, but we could circle
back and run the tests in a test-only entry somewhere later in the job
queue, if the package build setup can support it."

-- 
:wq

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 774 bytes --]

On 9/18/12 7:07 PM, Hans de Graaff wrote:
> On Tue, 2012-09-18 at 11:47 +0200, Michał Górny wrote:
>> 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.
> 
> It would enable us to consider making tests on some packages optional to
> break circular dependencies with FEATURES=test, i.e. only run the tests
> if the test dependencies can be installed without circular dependencies.
> 
> https://bugs.gentoo.org/show_bug.cgi?id=175808

Oh right, this is currently a mess, which makes arch testing more
difficult and slower.

I think it's important to break FEATURES=test circular dependencies.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

[gentoo-dev] Re: GLEP: gentoo sync based unified deps proposal

[Ryan Hill]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Sun, 16 Sep 2012 06:52:11 -0700
Brian Harring <ferringb@gmail.com> wrote:

> Folks-
> 
> Keeping it short and quick, a basic glep has been written for what I'm 
> proposing for DEPENDENCIES enhancement.
> 
> The live version of the doc is available at 
> http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html 
> 

*stamp* Ship it!


-- 
gcc-porting
toolchain, wxwidgets          we were never more here, expanse getting broader
@ gentoo.org                          but bigger boats been done by less water

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 535 bytes --]

On Sun, 16 Sep 2012 06:52:11 -0700
Brian Harring <ferringb@gmail.com> wrote:

> Keeping it short and quick, a basic glep has been written for what I'm 
> proposing for DEPENDENCIES enhancement.
> 
> The live version of the doc is available at 
> http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html 

One more question -- are we going to keep 'foo,bar?' syntax as
a special case applying only to dependency atoms or are we going to
extend it to USE flags?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Wed, Sep 26, 2012 at 08:58:54AM +0200, Micha?? G??rny wrote:
> On Sun, 16 Sep 2012 06:52:11 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> 
> > Keeping it short and quick, a basic glep has been written for what I'm 
> > proposing for DEPENDENCIES enhancement.
> > 
> > The live version of the doc is available at 
> > http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html 
> 
> One more question -- are we going to keep 'foo,bar?' syntax as
> a special case applying only to dependency atoms or are we going to
> extend it to USE flags?

It's fairly dep specific; that's effectivelly foo|bar when you think 
about it; it multiplies out to dep:foo? ( that block ) dep:bar? ( that 
block ) in a dumb PM (smarter one just leaves the tree collapsed and 
filters as it goes).

Phrased another way, I'm not sure we really need shorthand for the 
following:

x? ( blah )
y? ( blah )
z? ( blah )

into
x,y,z? ( blah )

It's a rare case; I could only foresee that potentially being of use 
for arch flags; ie, amd64,x86? ( blah ); which I'd write as 
"arch:amd64,x86? ( blah )" personally since I don't like the notion of 
introducing ',' into raw, non use group flags.

That said, I don't hugely care; people think it's useful, then have at 
it.
~harring

Re: [gentoo-dev] GLEP: gentoo sync based unified deps proposal

[Brian Harring]

On Wed, Sep 26, 2012 at 08:58:54AM +0200, Micha?? G??rny wrote:
> On Sun, 16 Sep 2012 06:52:11 -0700
> Brian Harring <ferringb@gmail.com> wrote:
> 
> > Keeping it short and quick, a basic glep has been written for what I'm 
> > proposing for DEPENDENCIES enhancement.
> > 
> > The live version of the doc is available at 
> > http://dev.gentoo.org/~ferringb/unified-dependencies/extensible_dependencies.html 
> 
> One more question -- are we going to keep 'foo,bar?' syntax as
> a special case applying only to dependency atoms or are we going to
> extend it to USE flags?

Note that's dep:foo,bar; not a bare "allow any use flags to be OR'd 
together".  In light of the fact it *is* just an expansion hack, the 
usage is semi limited although there are scenarios for it; arches, 
namely (if amd64 or x86, use this, if mips, that, etc).

I have no preference either way; extending it outside of dep isn't 
necessary if people hate it, although as said, there are some 
potential uses for it.

That said, if we were to start using it, the ',' as an 'or' operator 
mildly sucks; dep:build|run also sucks (hard to read), and 
dep:build+run, to me at least, implies 'and'.  And yep, bikeshedding 
potential there.

~harrin