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, 07:59 PM
Alexis Ballier
 
Default Unified DEPENDENCIES concept

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

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

Reference needed. You probably didn't even think more than 2 seconds
before making this claim about python.eclass, because it is not
particularly hard.
 
Old 09-07-2012, 08:07 PM
Michał Górny
 
Default Unified DEPENDENCIES concept

On Fri, 7 Sep 2012 20:25:58 +0100
Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:

> On Fri, 7 Sep 2012 21:21:42 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> > So... what is your issue in here, sir?
>
> The issue is what Zac, Ian and I were discussing, before you jumped in
> and started yelling. Repeating it for you:
>
> We want to know, for dependencies that are in DEPEND and not RDEPEND,
> whether or not most of them will become HDEPENDs, if dependencies are
> being expressed properly. If that is the case, then it makes more
> sense to introduce TDEPEND than HDEPEND.

The only person yelling here is you. I have politely asked a question,
and then you come with your wisdom not answering it at all. And if you
haven't noticed, my question was directed to Ian who -- unlike you --
may be able to say something meaningful in the topic rather than
diverging from it just to prove a random point only you know.

--
Best regards,
Michał Górny
 
Old 09-07-2012, 08:08 PM
Ian Stakenvicius
 
Default Unified DEPENDENCIES concept

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

On 07/09/12 02:52 PM, Ciaran McCreesh wrote:
> On Fri, 7 Sep 2012 20:46:48 +0200 Michał Górny <mgorny@gentoo.org>
> wrote:
>> Now, let me remind you because you probably fail to know the
>> world outside your dreamworld:
>>
>> (with HDEPEND/DEPEND) generally mean that we would need to
>> s/DEPEND/HDEPEND/ for the vast majority of ebuilds (ie all the
>> trivial ones)?
>>
>> That does effectively refer to the common depends as well. You
>> know, in the real world where there is no magical variables which
>> do miracles behind your back.
>
> Uhm, no, it doesn't. Things in both DEPEND and RDEPEND are an
> *entirely* different case when it comes to destinations, since
> RDEPEND goes to ROOT.
>
> The distinction between DEPEND and HDEPEND is relevant only for
> dependencies that are not also in RDEPEND.
>

Bringing it back to the issue it's solving:

Afaict, for migration:

- - DEPEND changes to HDEPEND
- - the new DEPEND now will be used for things that are *currently* in
RDEPEND and DEPEND (so that things will work) but are not actually
run-time dependencies. Said atoms will then be removed from RDEPEND
(and not be included in the new HDEPEND either) as they aren't really
supposed to be there in the first place.

Right?

(Note, I have no idea how this will play with PDEPEND but maybe some
of the current circular dependencies will also disappear?)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlBKVFUACgkQ2ugaI38ACPCcbwEAr2/+lQ70jPJ0AWp+hGQUo6YG
dFxOJPOoRpBnVlipvnoBAJgQmfB5fqK6lNQB5iJghQYhqRk5KC N4SZe7/lltRviA
=xDo8
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 08:10 PM
Michał Górny
 
Default Unified DEPENDENCIES concept

On Fri, 7 Sep 2012 16:59:48 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Fri, 7 Sep 2012 20:21:03 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
>
> > 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.
> >
>
> Reference needed. You probably didn't even think more than 2 seconds
> before making this claim about python.eclass, because it is not
> particularly hard.

Hmm, didn't it used to support having python as DEPEND only?

In any case, I'm thinking more of that line. Eclasses which sometimes
add RDEP+DEP, sometimes DEP only, and sometimes do even crazier things.

--
Best regards,
Michał Górny
 
Old 09-07-2012, 08:14 PM
Ian Stakenvicius
 
Default Unified DEPENDENCIES concept

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

On 07/09/12 04:10 PM, Michał Górny wrote:
> On Fri, 7 Sep 2012 16:59:48 -0300 Alexis Ballier
> <aballier@gentoo.org> wrote:
>
>> On Fri, 7 Sep 2012 20:21:03 +0200 Michał Górny
>> <mgorny@gentoo.org> wrote:
>>
>>> 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.
>>>
>>
>> Reference needed. You probably didn't even think more than 2
>> seconds before making this claim about python.eclass, because it
>> is not particularly hard.
>
> Hmm, didn't it used to support having python as DEPEND only?
>
> In any case, I'm thinking more of that line. Eclasses which
> sometimes add RDEP+DEP, sometimes DEP only, and sometimes do even
> crazier things.
>

Is there anything in particular in the spec/proposal for DEPENDENCIES
that would exclude the addition of individual "build: app-cat/myatom"
"run: app-cat/myatom" deps by an eclass or eclasses? I know the
"goal" here is to make things atom-centric, but I can't see an
implementation ever working of this that wouldn't permit the "pile-on"
of additional entries of different (or even the same) roles on
identical or near-identical atoms.

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

iF4EAREIAAYFAlBKVZkACgkQ2ugaI38ACPAdAwEAlGthSTR/jor93qpclC5Gl+Sl
82mjHm3ZObOC8Btf+SYA/AxaxCfHuWXoYKj5Ryo9CKna/7cdc1sUoV0fvacO9fja
=AoSy
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 08:14 PM
Ciaran McCreesh
 
Default Unified DEPENDENCIES concept

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

On Fri, 07 Sep 2012 16:08:53 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> Bringing it back to the issue it's solving:
>
> Afaict, for migration:
>
> - - DEPEND changes to HDEPEND

If we're going by Chromium, AFAICS they're only making this change when
they find they actually need it to get the resolver to give "the right
answer", and otherwise leaving DEPEND as-is. This strikes me as being
heavily in Doing It Wrong territory.

> - - the new DEPEND now will be used for things that are *currently* in
> RDEPEND and DEPEND (so that things will work) but are not actually
> run-time dependencies. Said atoms will then be removed from RDEPEND
> (and not be included in the new HDEPEND either) as they aren't really
> supposed to be there in the first place.

I'm not entirely sure that there are more than a handful of very
special cases that would be covered by the second point. Can anyone
provide examples?

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

iEYEARECAAYFAlBKVbQACgkQ96zL6DUtXhHcUwCfdNq3MSMyYB Ax19ImoOtWFMRM
l2UAoM6DfYJOCL4tLwZ3s6Jeh/6CzBCI
=FIrN
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 08:15 PM
Ciaran McCreesh
 
Default Unified DEPENDENCIES concept

On Fri, 7 Sep 2012 22:07:30 +0200
Michał Górny <mgorny@gentoo.org> wrote:
> On Fri, 7 Sep 2012 20:25:58 +0100
> Ciaran McCreesh <ciaran.mccreesh@googlemail.com> wrote:
> > On Fri, 7 Sep 2012 21:21:42 +0200
> > Michał Górny <mgorny@gentoo.org> wrote:
> > > So... what is your issue in here, sir?
> >
> > The issue is what Zac, Ian and I were discussing, before you jumped
> > in and started yelling. Repeating it for you:
> >
> > We want to know, for dependencies that are in DEPEND and not
> > RDEPEND, whether or not most of them will become HDEPENDs, if
> > dependencies are being expressed properly. If that is the case,
> > then it makes more sense to introduce TDEPEND than HDEPEND.
>
> The only person yelling here is you. I have politely asked a question,
> and then you come with your wisdom not answering it at all. And if you
> haven't noticed, my question was directed to Ian who -- unlike you --
> may be able to say something meaningful in the topic rather than
> diverging from it just to prove a random point only you know.

Ian and I are asking essentially the same question regarding the same
issue, and I believe you're the only interested person so far who has
had any difficulty understanding that. However, if hearing it from
someone other than me makes it easier for you to accept that there is
something to discuss, then you're welcome to pretend that everything
that I say from now on was written by someone other than me.

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

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

On 07/09/12 04:14 PM, Ciaran McCreesh wrote:
> On Fri, 07 Sep 2012 16:08:53 -0400 Ian Stakenvicius
> <axs@gentoo.org> wrote:
>> Bringing it back to the issue it's solving:
>
>> Afaict, for migration:
>
>> - - DEPEND changes to HDEPEND
>
> If we're going by Chromium, AFAICS they're only making this change
> when they find they actually need it to get the resolver to give
> "the right answer", and otherwise leaving DEPEND as-is. This
> strikes me as being heavily in Doing It Wrong territory.
>
>> - - the new DEPEND now will be used for things that are
>> *currently* in RDEPEND and DEPEND (so that things will work) but
>> are not actually run-time dependencies. Said atoms will then be
>> removed from RDEPEND (and not be included in the new HDEPEND
>> either) as they aren't really supposed to be there in the first
>> place.
>
> I'm not entirely sure that there are more than a handful of very
> special cases that would be covered by the second point. Can
> anyone provide examples?
>

Bug 263343 , the 'fontconfig' dep for some package i wasn't able to
find easily

Bug 317337 (original HDEPEND proposal) mentions the
x11-proto/xcb-proto dep for libxcb (and i assume anything else
depending on xcb-proto)

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

iF4EAREIAAYFAlBKWPgACgkQ2ugaI38ACPDUFQEAhOF99mIqr/TXTOGFgdBdARg3
RSPlU8GQpxyEP2x9GPoA/07BSSTfoObc8COCTlpiC+RQP4zbUMwWODazNCszi/hx
=BMvQ
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 08:40 PM
Ciaran McCreesh
 
Default Unified DEPENDENCIES concept

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

On Fri, 07 Sep 2012 16:28:40 -0400
Ian Stakenvicius <axs@gentoo.org> wrote:
> >> - - the new DEPEND now will be used for things that are
> >> *currently* in RDEPEND and DEPEND (so that things will work) but
> >> are not actually run-time dependencies. Said atoms will then be
> >> removed from RDEPEND (and not be included in the new HDEPEND
> >> either) as they aren't really supposed to be there in the first
> >> place.
> >
> > I'm not entirely sure that there are more than a handful of very
> > special cases that would be covered by the second point. Can
> > anyone provide examples?
>
> Bug 263343 , the 'fontconfig' dep for some package i wasn't able to
> find easily

Do we have an explanation as to *why* fontconfig has to be on ROOT
here? Is it because $ROOT/var/cache/fontconfig needs to exist at build
time, but not at runtime? If so, is this better fixed by using a
temporary directory?

> Bug 317337 (original HDEPEND proposal) mentions the
> x11-proto/xcb-proto dep for libxcb (and i assume anything else
> depending on xcb-proto)

That's a BADEPEND.

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

iEYEARECAAYFAlBKW7cACgkQ96zL6DUtXhG0iQCfdYgzb5kFYE/fN6iTAEJriyuR
zxwAoJi0PvK7JZVqaltliyJFlCZARQRj
=Tzgv
-----END PGP SIGNATURE-----
 
Old 09-07-2012, 10:55 PM
Michael Orlitzky
 
Default Unified DEPENDENCIES concept

On 09/07/2012 07:45 AM, Ciaran McCreesh wrote:
> Since DEPENDENCIES hasn't been written up in a Gentoo-friendly
> manner, and since the Exherbo documentation doesn't seem to suffice
> to explain the idea here, here's some more details on the
> DEPENDENCIES proposal.
>

It seems to me that the problem this solves is just one of ontology.
It's analogous to trying to stick files named "foo", "bar", "baz",
etc. into directories named "depend", "rdepend", "hdepend", and so on.

There are a few well-known ways to organize things in a hierarchy, and
which one is most efficient depends on the categories and objects that
you have. Given the way that most software is built (see:
COMMON_DEPEND), I think DEPENDENCIES would work better than what we're
doing now, but it also seems more complex.

I think that dependencies are ultimately not hierarchical, and this
can force duplication in DEPENDENCIES as well. Has anyone considered
tagging the package atoms with a list of dependency types? For example,

* foo/bar: ( build run host )
* baz/one: baz? ( build )
* baz/two, baz/three: baz? ( build run )
...

This would eliminate duplication of the objects (package atoms) in
favor of duplication of the categories (dependency types). Since the
package atoms are what we really care about, I think the tradeoff is
beneficial. Maintainers get to express each dependency exactly once.
 

Thread Tools




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

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