Hi!
As Ansgar requests technical solutions, here's one:
just like systemd-shim|systemd-sysv, switch the "init" package from
Pre-Depends: systemd-sysv | sysvinit-core | upstart
to
Pre-Depends: sysvinit-core | systemd-sysv | upstart
The set of packages installed by d-i / debootstrap is steered
Dimitri wrote:
> Thus multiarch cross tooling is not so relevant for fresh bootstraps,
> and/or targeting non-debian architectures, or otherwise incomplete
> systems (e.g. those that do not have compatible set of pre-compiled
> binaries that use multiarch-paths
I'll leave it to Helmut to talk abo
Hello,
On Sat, Nov 22, 2014 at 5:21 AM, Adam Borowski wrote:
> Hi!
> As Ansgar requests technical solutions, here's one:
>
> just like systemd-shim|systemd-sysv, switch the "init" package from
> Pre-Depends: systemd-sysv | sysvinit-core | upstart
> to
> Pre-Depends: sysvinit-core | systemd-sy
On Sat, Nov 22, 2014 at 9:01 AM, Cameron Norman
wrote:
> Hello,
>
> On Sat, Nov 22, 2014 at 5:21 AM, Adam Borowski wrote:
>> Hi!
>> As Ansgar requests technical solutions, here's one:
>>
>> just like systemd-shim|systemd-sysv, switch the "init" package from
>> Pre-Depends: systemd-sysv | sysvin
]] Adam Borowski
> The set of packages installed by d-i / debootstrap is steered by hard-coded
> scripts, thus new systems can default to whatever is set there.
This has not been true for many years. (sarge seems to be the last one
where it was true, and etch is the first that uses the prioritie
Hi,
Adam Borowski writes:
> As Ansgar requests technical solutions, here's one:
>
> just like systemd-shim|systemd-sysv, switch the "init" package from
> Pre-Depends: systemd-sysv | sysvinit-core | upstart
> to
> Pre-Depends: sysvinit-core | systemd-sysv | upstart
>From a simple test this se
On 21 November 2014 at 19:21, Sam Hartman wrote:
>> "Dimitri" == Dimitri John Ledkov writes:
>
> Dimitri> Comparing squeeze and jessies - have things regressed? if
> Dimitri> yes, how? As far as I expect, the way one uses debian
> Dimitri> source packaging to produce cross toolch
On 22 November 2014 at 16:21, Ron wrote:
>
> Dimitri wrote:
>> Thus multiarch cross tooling is not so relevant for fresh bootstraps,
>> and/or targeting non-debian architectures, or otherwise incomplete
>> systems (e.g. those that do not have compatible set of pre-compiled
>> binaries that use mul
Reading this bug report title & history, it is very misleading.
Building cross-toolchains, and cross-toolchains that are multiarch
compatible has been possible to do before (stable) and is possible in
current planned release (testing).
I have provided the documentation links to that in
https://bu
Adam Borowski (2014-11-22):
> Hi!
> As Ansgar requests technical solutions, here's one:
>
> just like systemd-shim|systemd-sysv, switch the "init" package from
> Pre-Depends: systemd-sysv | sysvinit-core | upstart
> to
> Pre-Depends: sysvinit-core | systemd-sysv | upstart
>
> The set of pack
On Sat, Nov 22, 2014 at 06:15:44PM +0100, Tollef Fog Heen wrote:
> > The set of packages installed by d-i / debootstrap is steered by hard-coded
> > scripts, thus new systems can default to whatever is set there.
>
> This has not been true for many years. (sarge seems to be the last one
> where it
Hello everyone,
Since I myself and some others had some criticisms and/or doubts of
Adam Borowski's proposal, I would like to propose a different one.
With this I hope to:
* make new installations use systemd-sysv (with no reliance on
undefined or inconsistent behavior from the various ways of s
On Sat, Nov 22, 2014 at 05:29:42PM -0800, Cameron Norman wrote:
> I would like to propose a different one.
[...]
>
> So, the change would be that: the sysvinit package would cease being a
> transition / shim package, however it would not signal that a user
> explicitly installed sysvinit; sysvinit
13 matches
Mail list logo