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, 12:25 PM
Ian Stakenvicius
 
Default GLEP: gentoo sync based unified deps proposal

-----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-----
 
Old 09-18-2012, 01:27 PM
Ian Stakenvicius
 
Default GLEP: gentoo sync based unified deps proposal

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

iF0EAREIAAYFAlBYdqYACgkQ2ugaI38ACPB41gD4ygy9SxFODJ b/TlUp+23cZ36s
D+/c6gCaGXIPVoDGlQD/fsE6TcBsDnovBTVA0db4s811rTuih7JpX5LRDuABjfk=
=0eGL
-----END PGP SIGNATURE-----
 
Old 09-18-2012, 05:07 PM
Hans de Graaff
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 09-18-2012, 05:18 PM
Michael Mol
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 09-18-2012, 05:21 PM
"Paweł Hajdan, Jr."
 
Default GLEP: gentoo sync based unified deps proposal

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.
 
Old 09-18-2012, 07:18 PM
Alec Warner
 
Default GLEP: gentoo sync based unified deps proposal

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
>
 
Old 09-18-2012, 07:25 PM
Zac Medico
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 09-18-2012, 07:29 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 09-18-2012, 07:40 PM
Zac Medico
 
Default GLEP: gentoo sync based unified deps proposal

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
 
Old 09-18-2012, 07:44 PM
Ciaran McCreesh
 
Default GLEP: gentoo sync based unified deps proposal

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
 

Thread Tools




All times are GMT. The time now is 07:37 PM.

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