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-07-2012, 04:53 PM
Zac Medico
 
Default Unified DEPENDENCIES concept

On 09/07/2012 09:10 AM, Ciaran McCreesh wrote:
> On Fri, 7 Sep 2012 12:46:41 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
>> For example, what is the HDEPEND equivalent for DEPENDENCIES ? exherbo
>> documentation doesn't seem to mention an equivalent label.
>
> DEPENDENCIES is essentially independent of what label names we
> introduce. I get the impression Gentoo will be bikeshedding, er, I mean
> selecting shorter names for some of the labels than what Exherbo is
> using. So HDEPEND could be 'host' if you like.
>
> In any case, the reason you don't see a 'host' label on Exherbo is
> because it's called 'build'. Exherbo's taken a more comprehensive
> approach to handling ROOT-related dependencies -- dependency resolution
> for ROOT!=/ still uses / for satisfying not-purely-runtimeish
> dependencies, and then has a way of locking versions on / to versions
> in ROOT. It does rely upon having a fully-ROOT-and-/-aware resolver,
> though, so it may not be suitable for Gentoo.

If you're insinuating that Portage may not have a
"fully-ROOT-and-/-aware resolver", then I can assure you that this is
not a problem. The only reason that Portage currently doesn't have "a
way of locking versions on / to versions in ROOT" is that none of the
existing EAPIs have a way to express this kind of dependency constraint.
--
Thanks,
Zacd
 
Old 09-07-2012, 04:58 PM
Ciaran McCreesh
 
Default Unified DEPENDENCIES concept

On Fri, 07 Sep 2012 09:53:46 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> If you're insinuating that Portage may not have a
> "fully-ROOT-and-/-aware resolver", then I can assure you that this is
> not a problem.

In that case, why do we need HDEPEND at all?

--
Ciaran McCreesh
 
Old 09-07-2012, 05:02 PM
Ian Stakenvicius
 
Default Unified DEPENDENCIES concept

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

On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico <zmedico@gentoo.org>
> wrote:
>> If you're insinuating that Portage may not have a
>> "fully-ROOT-and-/-aware resolver", then I can assure you that
>> this is not a problem.
>
> In that case, why do we need HDEPEND at all?
>

We don't, actually; HDEPEND is essentially DEPEND. what we need is
TDEPEND.


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

iF4EAREIAAYFAlBKKKgACgkQ2ugaI38ACPBHFgD/Y7drSHcrEnjNuQZ2bbkLgXPh
6g1KmT4u2xljTR0WergA/jc80lQ2Zy7L3CI2Hn9kyy6cmyZ7yTHJHn5ysdAZkTbS
=kdVT
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 05:31 PM
Zac Medico
 
Default Unified DEPENDENCIES concept

On 09/07/2012 09:58 AM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 09:53:46 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> If you're insinuating that Portage may not have a
>> "fully-ROOT-and-/-aware resolver", then I can assure you that this is
>> not a problem.
>
> In that case, why do we need HDEPEND at all?

With existing EAPIs, it's possible to use DEPEND for host buildtime-only
deps, RDEPEND for target build+run deps, and PDEPEND for target
runtime-only deps. However, there's no way to to specify buildtime-only
target deps (that aren't needed at runtime). The HDEPEND proposal
involves solves this by using HDEPEND for host buildtime-only deps, and
DEPEND for target buildtime-only deps.
--
Thanks,
Zac
 
Old 09-07-2012, 05:40 PM
Alexis Ballier
 
Default Unified DEPENDENCIES concept

On Fri, 7 Sep 2012 18:03:51 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 7 Sep 2012 12:46:41 -0300
> Alexis Ballier <aballier@gentoo.org> wrote:
>
> > I actually do like the concept but I'm not sure we can reach
> > consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
> > people used to it could be to have two parallel EAPIs, like 6 and
> > 6-dependencies, where the former will keep the old style and the
> > latter use DEPENDENCIES.
>
> With eclasses supporting both of them? That's more than crazy.

depstr=cat/foo

case $EAPI in
*-dependencies) DEPENDENCIES="build+run: $depstr";;
*) DEPEND="$depstr"
RDEPEND="$depstr";;
esac


Yes, eclasses supporting more than one EAPI is crazy and we should
create a new eclass for every EAPI


> > After some time has passed, it could be decided to kill the less
> > useful one, say in EAPI 8, and get only one 'latest' EAPI again.
> > This decision doesn't need to be left only to the council, but
> > since it affects everyone it could be a vote from all the dev
> > community.
>
> Why the dev community only? We have many active contributors who
> aren't devs and who work hard with ebuilds. It's *their* time which
> will be wasted on rewriting dependencies into new form, not yours.

It seems we have a different definition of 'dev community'. That's true
we have well established voting procedures for gentoo devs or foundation
members, but feel free to propose one for the rest of contributors.

> > There is also the possibility that a consensus will never be reached
> > and that the two styles will have to live forever, but after all,
> > the EAPI concept is made for this.
>
> I believe the correct concept is 'fork'. And that's what Exherbo did.

An EAPI is a fork of the ebuild API already. Exherbo is not a fork as
far as I know, or at least not more than Gentoo is a Redhat fork
because it can process rpm's.

A.
 
Old 09-07-2012, 05:40 PM
Zac Medico
 
Default Unified DEPENDENCIES concept

On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
>> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico <zmedico@gentoo.org>
>> wrote:
>>> If you're insinuating that Portage may not have a
>>> "fully-ROOT-and-/-aware resolver", then I can assure you that
>>> this is not a problem.
>
>> In that case, why do we need HDEPEND at all?
>
>
> We don't, actually; HDEPEND is essentially DEPEND. what we need is
> TDEPEND.

We could do either one (or do both, and get rid of DEPEND). In
discussions on the chromium-os-dev list [1] (people who could have been
using HDEPEND for years now), the dominant preference was to use HDEPEND
since they felt that it would require the least amount of adjustment to
existing DEPEND settings.

[1]
https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
--
Thanks,
Zac
 
Old 09-07-2012, 05:58 PM
Ian Stakenvicius
 
Default Unified DEPENDENCIES concept

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

On 07/09/12 01:40 PM, Zac Medico wrote:
> On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
>> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
>>> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico
>>> <zmedico@gentoo.org> wrote:
>>>> If you're insinuating that Portage may not have a
>>>> "fully-ROOT-and-/-aware resolver", then I can assure you
>>>> that this is not a problem.
>>
>>> In that case, why do we need HDEPEND at all?
>>
>>
>> We don't, actually; HDEPEND is essentially DEPEND. what we need
>> is TDEPEND.
>
> We could do either one (or do both, and get rid of DEPEND). In
> discussions on the chromium-os-dev list [1] (people who could have
> been using HDEPEND for years now), the dominant preference was to
> use HDEPEND since they felt that it would require the least amount
> of adjustment to existing DEPEND settings.
>
> [1]
> https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE


Thanks
>
for clarifying this; after reading through the bug I wasn't
sure if the recommendation was to add HDEPEND only or to deprecate
DEPEND entirely for HDEPEND/TDEPEND.

Just to clarify the work involved in converting to this; since DEPEND
on EAPI<=4 is essentially HDEPEND , wouldn't migration to the new EAPI
(with HDEPEND/DEPEND) generally mean that we would need to
s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the trivial
ones)?

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

iF4EAREIAAYFAlBKNagACgkQ2ugaI38ACPD7fAD+ItO84yPGTt G5G9aY0nJvTheA
QP4CRV8euHOUeCt1CGsBAK0DbpLXnARHd6lHYCAnuihezRRYr8 rO8xw7kIKmlx/U
=DkxI
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 06:18 PM
Zac Medico
 
Default Unified DEPENDENCIES concept

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

On 09/07/2012 10:58 AM, Ian Stakenvicius wrote:
> On 07/09/12 01:40 PM, Zac Medico wrote:
>> On 09/07/2012 10:02 AM, Ian Stakenvicius wrote:
>>> On 07/09/12 12:58 PM, Ciaran McCreesh wrote:
>>>> On Fri, 07 Sep 2012 09:53:46 -0700 Zac Medico
>>>> <zmedico@gentoo.org> wrote:
>>>>> If you're insinuating that Portage may not have a
>>>>> "fully-ROOT-and-/-aware resolver", then I can assure you
>>>>> that this is not a problem.
>>>
>>>> In that case, why do we need HDEPEND at all?
>>>
>>>
>>> We don't, actually; HDEPEND is essentially DEPEND. what we
>>> need is TDEPEND.
>
>> We could do either one (or do both, and get rid of DEPEND). In
>> discussions on the chromium-os-dev list [1] (people who could
>> have been using HDEPEND for years now), the dominant preference
>> was to use HDEPEND since they felt that it would require the
>> least amount of adjustment to existing DEPEND settings.
>
>> [1]
>> https://groups.google.com/a/chromium.org/forum/?fromgroups=#!topic/chromium-os-dev/yVAcpfZHrOE
>
>>
>
> Thanks
>
> for clarifying this; after reading through the bug I wasn't sure if
> the recommendation was to add HDEPEND only or to deprecate DEPEND
> entirely for HDEPEND/TDEPEND.
>
> Just to clarify the work involved in converting to this; since
> DEPEND on EAPI<=4 is essentially HDEPEND , wouldn't migration to
> the new EAPI (with HDEPEND/DEPEND) generally mean that we would
> need to s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all
> the trivial ones)?

In the linked chromium-os-dev discussion, the consensus seemed to be
that migrating deps from DEPEND to HDEPEND would result in fewer
overall changes than migrating deps from DEPEND to TDEPEND. For this
reason, the dominant preference was to go with HDEPEND.
- --
Thanks,
Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBKOnQACgkQ/ejvha5XGaNguwCg01LvwyvD2AcUG2sTMdTakjuH
P4EAniQQpndputGCSLTcRB2VeZcfFhIj
=5idF
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 06:21 PM
Michał Górny
 
Default Unified DEPENDENCIES concept

On Fri, 7 Sep 2012 14:40:25 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Fri, 7 Sep 2012 18:03:51 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > On Fri, 7 Sep 2012 12:46:41 -0300
> > Alexis Ballier <aballier@gentoo.org> wrote:
> >
> > > I actually do like the concept but I'm not sure we can reach
> > > consensus about '*DEPEND vs DEPENDENCIES'; a possibility to get
> > > people used to it could be to have two parallel EAPIs, like 6 and
> > > 6-dependencies, where the former will keep the old style and the
> > > latter use DEPENDENCIES.
> >
> > With eclasses supporting both of them? That's more than crazy.
>
> depstr=cat/foo
>
> case $EAPI in
> *-dependencies) DEPENDENCIES="build+run: $depstr";;
> *) DEPEND="$depstr"
> RDEPEND="$depstr";;
> esac

Yes, we have many eclasses where this is actually the only expected
result. Maybe start with python.eclass, that should be quite an extreme
example.

--
Best regards,
Michał Górny
 
Old 09-07-2012, 06:23 PM
Ciaran McCreesh
 
Default Unified DEPENDENCIES concept

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

On Fri, 07 Sep 2012 11:18:28 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> In the linked chromium-os-dev discussion, the consensus seemed to be
> that migrating deps from DEPEND to HDEPEND would result in fewer
> overall changes than migrating deps from DEPEND to TDEPEND. For this
> reason, the dominant preference was to go with HDEPEND.

They're looking at "minimum number of changes to make it appear to
work", not "minimum number of changes to express dependencies
correctly".

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

iEYEARECAAYFAlBKO44ACgkQ96zL6DUtXhHGDwCgi66mZCVH0U WdB8yfJxl8lcuR
QPkAnRgziWGLpMbJ1i92CXjRJ1Q2tWzJ
=S+jv
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 02:26 AM.

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