FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 10-01-2012, 07:13 AM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 10-01-2012, 09:01 AM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 10-01-2012, 09:15 AM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 10-02-2012, 05:51 PM
Ian Stakenvicius
 
Default GLEP: gentoo sync based unified deps proposal

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

iF4EAREIAAYFAlBrKYUACgkQ2ugaI38ACPAMJAD9FzCH4ifbka nbC17w2KGjMHP7
G4qBrJ9v2dd7sHV338EA/iK/J+NZosc+M7wefJ8J6fU4mVczlM4WiOkCNVsTSO6w
=Io2B
-----END PGP SIGNATURE-----
 
Old 10-02-2012, 05:56 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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

iEYEARECAAYFAlBrKsEACgkQ96zL6DUtXhEyOACfQgN7K9iPf0 o8NF4w95HpFq3j
MHQAoKwMwmbJHuF65PIX9b6W0EQLqukl
=pzQn
-----END PGP SIGNATURE-----
 
Old 10-02-2012, 06:08 PM
Ian Stakenvicius
 
Default GLEP: gentoo sync based unified deps proposal

-----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+KnH0izbhJZ uhm0JD1cHG6s0D
4/0gxZk3Z+TEy9I0W84A/1Yt0ilqJ0SfNTHr9P6hjQkUvLsHzPzkh4Kiz8VMah/w
=8amf
-----END PGP SIGNATURE-----
 
Old 10-02-2012, 06:16 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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

iEYEARECAAYFAlBrL2kACgkQ96zL6DUtXhE1EgCeNANLVxtyb6 OSir9LqA+PB+bJ
zUkAn2dV2OjMYMB95+tBUYvb3Eda4rU7
=0Cwb
-----END PGP SIGNATURE-----
 
Old 10-02-2012, 08:40 PM
Brian Harring
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 10-02-2012, 08:46 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 10-14-2012, 04:38 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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
 

Thread Tools




All times are GMT. The time now is 03:41 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org