Hey all.
Regarding updates breaking the system, NixOS might be worth a try.
The functional nature of the package manager there lets you try out an
update, either live or in a VM, as well as roll back to the old
configuration in case of problems. Due to the design there's no risk
in building update
> Init.d scripts are programs - they could probably do just about anything.
They couldn't monitor a process and restart it when it crashes, as
specified by the restart options in the unit file. That is, without
significant modifications in the way OpenRC works, such as adding a
monitoring process,
I *really* hate those virtual dependencies that don't actually satisfy
a real dependency, and require manual choice-specific intervention by
the user anyway. For example, packages that build external kernel
modules tend to depend on virtual/kernel-sources. However, this
dependency doesn't make sure
ysroot semantic there, which is available via use sysroot)
If all is well, I'll proceed to implement this.
On Sat, Sep 22, 2012 at 7:01 PM, Zac Medico wrote:
> On 09/22/2012 09:48 AM, Ambroz Bizjak wrote:
>> Zac, I think you misunderstood me here. Crosscompile-only HDEPEND is
>&
~${CATEGORY}/${P} )"
root_not_slash (or another name) would essentially be a superset of
crosscompile, since crosscompile implies ROOT!=/.
P.S. sorry Zac I sent you this twice, damn GMail :)
On Sat, Sep 22, 2012 at 6:31 PM, Zac Medico wrote:
> On 09/22/2012 09:08 AM, Ambroz Bizjak wrote:
>
ill break. This would
ease configuration and reduce the number of cases to be tested.
On Fri, Sep 21, 2012 at 6:06 PM, Zac Medico wrote:
> On 09/20/2012 10:34 AM, Ambroz Bizjak wrote:
>> The question now is, how should this method for checking
>> --crosscompile be implemented?
I'm working on some EAPI extensions with the goal of making Portage
more powerful for cross-compilation. See
https://bugs.gentoo.org/show_bug.cgi?id=317337
Currently, it's come down to the following:
- A new dependency type HDEPEND for packages which must be installed
in / at build time. With HDEP
