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 09-18-2012, 08:25 AM
Michał Górny
 
Default GLEP: gentoo sync based unified deps proposal

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

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
 
Old 09-18-2012, 09:38 AM
Ulrich Mueller
 
Default GLEP: gentoo sync based unified deps proposal

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

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
 
Old 09-18-2012, 09:47 AM
Michał Górny
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 09-18-2012, 09:56 AM
"vivo75@gmail.com"
 
Default GLEP: gentoo sync based unified deps proposal

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

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
 
Old 09-18-2012, 10:35 AM
Ulrich Mueller
 
Default GLEP: gentoo sync based unified deps proposal

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

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
 
Old 09-18-2012, 12:11 PM
Ulrich Mueller
 
Default GLEP: gentoo sync based unified deps proposal

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

Thread Tools




All times are GMT. The time now is 09:24 PM.

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