Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Gentoo Development (http://www.linux-archive.org/gentoo-development/)
-   -   HDEPEND (host dependencies for cross-compilation) for EAPI 5? (http://www.linux-archive.org/gentoo-development/699569-hdepend-host-dependencies-cross-compilation-eapi-5-a.html)

Zac Medico 08-31-2012 08:03 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
For those who may not know, chromium-os currently uses a
hard-host-depends ebuild as a workaround for our lack of HDEPEND support
[1]. We could easily add HDEPEND in EAPI 5 if we want, since we already
have a Portage patch attached to bug #317337 [2]. Here is a summary of
what that Portage patch will do:

In EAPI 5 or later, DEPEND has been divided into two parts:
DEPEND for build-time target dependencies, and HDEPEND for
build-time host dependencies. This division is designed
specifically to minimize difficulty in the process of
adapting ebuilds that were written for earlier EAPIs,
and therefore it also minimizes the adjustments that
ebuild developers will have to make to the thought
processes involved when writing ebuilds from scratch. In
an environment that does not involve cross-compilation,
HDEPEND behaves the same as DEPEND. When an ebuild is
converted from EAPI 4 or earlier to EAPI 5 or later,
in order to support cross-compilation environments, some
dependencies may need to be migrated to HDEPEND.

For ebuilds that have EAPI 5 or later, the emerge
--root-deps option has no effect since it is made obsolete
by division between DEPEND and HDEPEND. If EAPI 4 or
earlier ebuilds are used in combination with EAPI 5 or
later ebuilds, the --root-deps behavior will still be
applied to the EAPI 4 or earlier ebuilds (there is no
behavior change for ebuilds having older EAPIs).

[1]
http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq
[2] https://bugs.gentoo.org/show_bug.cgi?id=317337
--
Thanks,
Zac

Richard Yao 08-31-2012 08:39 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
On 08/31/2012 04:03 PM, Zac Medico wrote:
> For those who may not know, chromium-os currently uses a
> hard-host-depends ebuild as a workaround for our lack of HDEPEND support
> [1]. We could easily add HDEPEND in EAPI 5 if we want, since we already
> have a Portage patch attached to bug #317337 [2]. Here is a summary of
> what that Portage patch will do:
>
> In EAPI 5 or later, DEPEND has been divided into two parts:
> DEPEND for build-time target dependencies, and HDEPEND for
> build-time host dependencies. This division is designed
> specifically to minimize difficulty in the process of
> adapting ebuilds that were written for earlier EAPIs,
> and therefore it also minimizes the adjustments that
> ebuild developers will have to make to the thought
> processes involved when writing ebuilds from scratch. In
> an environment that does not involve cross-compilation,
> HDEPEND behaves the same as DEPEND. When an ebuild is
> converted from EAPI 4 or earlier to EAPI 5 or later,
> in order to support cross-compilation environments, some
> dependencies may need to be migrated to HDEPEND.
>
> For ebuilds that have EAPI 5 or later, the emerge
> --root-deps option has no effect since it is made obsolete
> by division between DEPEND and HDEPEND. If EAPI 4 or
> earlier ebuilds are used in combination with EAPI 5 or
> later ebuilds, the --root-deps behavior will still be
> applied to the EAPI 4 or earlier ebuilds (there is no
> behavior change for ebuilds having older EAPIs).
>
> [1]
> http://www.chromium.org/chromium-os/how-tos-and-troubleshooting/portage-build-faq
> [2] https://bugs.gentoo.org/show_bug.cgi?id=317337

I like this. It has my support.

Ciaran McCreesh 08-31-2012 08:46 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
On Fri, 31 Aug 2012 13:03:00 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> For those who may not know, chromium-os currently uses a
> hard-host-depends ebuild as a workaround for our lack of HDEPEND
> support [1]. We could easily add HDEPEND in EAPI 5 if we want, since
> we already have a Portage patch attached to bug #317337 [2]. Here is
> a summary of what that Portage patch will do:
>
> In EAPI 5 or later, DEPEND has been divided into two parts:
> DEPEND for build-time target dependencies, and HDEPEND for
> build-time host dependencies. This division is designed
> specifically to minimize difficulty in the process of
> adapting ebuilds that were written for earlier EAPIs,
> and therefore it also minimizes the adjustments that
> ebuild developers will have to make to the thought
> processes involved when writing ebuilds from scratch. In
> an environment that does not involve cross-compilation,
> HDEPEND behaves the same as DEPEND. When an ebuild is
> converted from EAPI 4 or earlier to EAPI 5 or later,
> in order to support cross-compilation environments, some
> dependencies may need to be migrated to HDEPEND.
>
> For ebuilds that have EAPI 5 or later, the emerge
> --root-deps option has no effect since it is made obsolete
> by division between DEPEND and HDEPEND. If EAPI 4 or
> earlier ebuilds are used in combination with EAPI 5 or
> later ebuilds, the --root-deps behavior will still be
> applied to the EAPI 4 or earlier ebuilds (there is no
> behavior change for ebuilds having older EAPIs).

What exactly would the rules be for handling a package that is in both
DEPEND and HDEPEND, when ROOT is in effect? Would the versions be
expected to match? What about use flags?

Also, we're getting rather a lot of *DEPEND variables here... If we're
making people make major changes to their deps, which for HDEPEND we
definitely would be, then the "it's expensive since people would have
to redo their deps" argument against a combined DEPENDENCIES variable
goes out of the window, so we should rethink that too.

--
Ciaran McCreesh

Zac Medico 08-31-2012 09:11 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
On 08/31/2012 01:46 PM, Ciaran McCreesh wrote:
> On Fri, 31 Aug 2012 13:03:00 -0700
> What exactly would the rules be for handling a package that is in both
> DEPEND and HDEPEND, when ROOT is in effect? Would the versions be
> expected to match? What about use flags?

For the sake of simplicity, I would treat them as entirely independent.
It should be easy enough for users to apply manual configuration
adjustments in order to resolve any conflicts of this nature that may
arise. If there turns out to be a strong demand for additional
constraints, we can consider adding them in a future EAPI (possibly
using a combined DEPENDENCIES variable).

> Also, we're getting rather a lot of *DEPEND variables here... If we're
> making people make major changes to their deps, which for HDEPEND we
> definitely would be,

Well, I not sure that "major changes" is a really good characterization.
We're just talking about migrating a few things from DEPEND to HDEPEND,
and it's not strictly required. The migration is only needed when
fulfilling a request to support cross-compilation in a particular ebuild.

> then the "it's expensive since people would have
> to redo their deps" argument against a combined DEPENDENCIES variable
> goes out of the window, so we should rethink that too.
--
Thanks,
Zac

Fabio Erculiani 08-31-2012 09:40 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
I like this as well.
However, since we're going to introduce a *DEPEND split, how about
splitting PDEPEND as well?

As far as I've seen, PDEPEND has two (or more?) different meanings:
- advisory (for instance, informing users about plugins)
- cycle-breaking to help the dependency solver

Would it be possible to add support for ODEPEND (as in "optional"
dependencies -- I don't really care about the variable name) as well?
This would be quite beneficial under certain circumstances. One of
these is when ebuilds are shipped with PDEPENDs which are not required
at runtime nor for cycle-breaking...

Another scenario in where ODEPEND would be nice to have is with
systemd init files pulled in by USE=systemd (and generally use? (
sys-apps/systemd ) in *DEPEND). Providing full systemd support for all
the packages without forcing users to have it installed, given that
openrc is the de-facto standard init system in Gentoo (and we don't
have any openrc? ( sys-apps/openrc )), would be a nice features for
binpkg repos. Users could then choose to enable or disable ODEPEND
during dependencies calculation via make.conf or argv.

I don't want to diverge too much from the HDEPEND discussion, but I
think that if we're going to split *DEPEND, it might be a good
opportunity to do it right _once_ and _for all_.

--
Fabio Erculiani

Ciaran McCreesh 08-31-2012 09:50 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
On Fri, 31 Aug 2012 23:40:27 +0200
Fabio Erculiani <lxnay@gentoo.org> wrote:
> Would it be possible to add support for ODEPEND (as in "optional"
> dependencies -- I don't really care about the variable name) as well?
> This would be quite beneficial under certain circumstances. One of
> these is when ebuilds are shipped with PDEPENDs which are not required
> at runtime nor for cycle-breaking...

This is what we call "suggestions" and SDEPEND. There are already two
proposals for dealing with this general issue.

--
Ciaran McCreesh

Ciaran McCreesh 08-31-2012 09:53 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
On Fri, 31 Aug 2012 14:11:38 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> On 08/31/2012 01:46 PM, Ciaran McCreesh wrote:
> > On Fri, 31 Aug 2012 13:03:00 -0700
> > What exactly would the rules be for handling a package that is in
> > both DEPEND and HDEPEND, when ROOT is in effect? Would the versions
> > be expected to match? What about use flags?
>
> For the sake of simplicity, I would treat them as entirely
> independent. It should be easy enough for users to apply manual
> configuration adjustments in order to resolve any conflicts of this
> nature that may arise. If there turns out to be a strong demand for
> additional constraints, we can consider adding them in a future EAPI
> (possibly using a combined DEPENDENCIES variable).

The thing is... Without some kind of "the same" constraint, we'd be
adding a feature which would probably work most of the time only by
coincidence.

> > Also, we're getting rather a lot of *DEPEND variables here... If
> > we're making people make major changes to their deps, which for
> > HDEPEND we definitely would be,
>
> Well, I not sure that "major changes" is a really good
> characterization. We're just talking about migrating a few things
> from DEPEND to HDEPEND, and it's not strictly required. The migration
> is only needed when fulfilling a request to support cross-compilation
> in a particular ebuild.

Where are you getting "a few" from? Is this "a few seems to be enough
to make it work", or "someone carefully analysed lots of packages to
work out exactly what dependencies are HDEPEND, and measured it"? I
strongly suspect we're in "works by coincidence" territory again --
"adding packages to HDEPEND as breakages are encountered" is a long way
from "having an accurate HDEPEND". Are we aiming for the former or the
latter?

--
Ciaran McCreesh

Zac Medico 08-31-2012 09:58 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
On 08/31/2012 02:40 PM, Fabio Erculiani wrote:
> I like this as well.
> However, since we're going to introduce a *DEPEND split, how about
> splitting PDEPEND as well?
>
> As far as I've seen, PDEPEND has two (or more?) different meanings:
> - advisory (for instance, informing users about plugins)
> - cycle-breaking to help the dependency solver
>
> Would it be possible to add support for ODEPEND (as in "optional"
> dependencies -- I don't really care about the variable name) as well?
> This would be quite beneficial under certain circumstances. One of
> these is when ebuilds are shipped with PDEPENDs which are not required
> at runtime nor for cycle-breaking...
>
> Another scenario in where ODEPEND would be nice to have is with
> systemd init files pulled in by USE=systemd (and generally use? (
> sys-apps/systemd ) in *DEPEND). Providing full systemd support for all
> the packages without forcing users to have it installed, given that
> openrc is the de-facto standard init system in Gentoo (and we don't
> have any openrc? ( sys-apps/openrc )), would be a nice features for
> binpkg repos. Users could then choose to enable or disable ODEPEND
> during dependencies calculation via make.conf or argv.
>
> I don't want to diverge too much from the HDEPEND discussion, but I
> think that if we're going to split *DEPEND, it might be a good
> opportunity to do it right _once_ and _for all_.

For optional dependencies, I'm pretty happy with the "runtime-switchable
USE flags" proposal:

https://gist.github.com/2945569
--
Thanks,
Zac

Ciaran McCreesh 08-31-2012 10:15 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
On Fri, 31 Aug 2012 14:58:49 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> For optional dependencies, I'm pretty happy with the
> "runtime-switchable USE flags" proposal:
>
> https://gist.github.com/2945569

Do we have an implementation of this yet? I have extreme doubts about
the viability of the idea...

--
Ciaran McCreesh

Zac Medico 08-31-2012 10:16 PM

HDEPEND (host dependencies for cross-compilation) for EAPI 5?
 
On 08/31/2012 02:53 PM, Ciaran McCreesh wrote:
> On Fri, 31 Aug 2012 14:11:38 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> On 08/31/2012 01:46 PM, Ciaran McCreesh wrote:
>>> On Fri, 31 Aug 2012 13:03:00 -0700
>>> What exactly would the rules be for handling a package that is in
>>> both DEPEND and HDEPEND, when ROOT is in effect? Would the versions
>>> be expected to match? What about use flags?
>>
>> For the sake of simplicity, I would treat them as entirely
>> independent. It should be easy enough for users to apply manual
>> configuration adjustments in order to resolve any conflicts of this
>> nature that may arise. If there turns out to be a strong demand for
>> additional constraints, we can consider adding them in a future EAPI
>> (possibly using a combined DEPENDENCIES variable).
>
> The thing is... Without some kind of "the same" constraint, we'd be
> adding a feature which would probably work most of the time only by
> coincidence.

Shrug, I don't do any cross-compilation myself, but maybe someone who
does could comment on the usefulness of this kind of constraint. Mike?
Brian?

>>> Also, we're getting rather a lot of *DEPEND variables here... If
>>> we're making people make major changes to their deps, which for
>>> HDEPEND we definitely would be,
>>
>> Well, I not sure that "major changes" is a really good
>> characterization. We're just talking about migrating a few things
>> from DEPEND to HDEPEND, and it's not strictly required. The migration
>> is only needed when fulfilling a request to support cross-compilation
>> in a particular ebuild.
>
> Where are you getting "a few" from? Is this "a few seems to be enough
> to make it work", or "someone carefully analysed lots of packages to
> work out exactly what dependencies are HDEPEND, and measured it"? I
> strongly suspect we're in "works by coincidence" territory again --
> "adding packages to HDEPEND as breakages are encountered" is a long way
> from "having an accurate HDEPEND". Are we aiming for the former or the
> latter?

I would think of it like prefix support in EAPI 3. Ebuilds using EAPI 3
were not required to support prefix. Similarly, ebuilds using EAPI 5
will not be required to support cross-compilation.
--
Thanks,
Zac


All times are GMT. The time now is 08:04 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.