Hi,
Tollef Fog Heen:
> > I am not sure if this matters, but it seems to me that this
> > procedure depends upon a specific sequence of package uploads
> > and system upgrades in the field.
>
> It does not. We just don't want to leave the archive in a state where
> it's easy to end up with the ne
On Thu, Jul 17, 2014 at 09:10:24PM +0200, Michael Banck wrote:
> > Looking at the policy again, I think extra is (mis)used quite too
> > often.
>
> Part of the problem could be that dh_make at least at one point (maybe
> still does) put "extra" as defalt Priority in its templates and it
> might've
On Thu, Jul 17, 2014 at 04:53:26PM +0200, Luca Falavigna wrote:
> Looking at the policy again, I think extra is (mis)used quite too
> often.
Part of the problem could be that dh_make at least at one point (maybe
still does) put "extra" as defalt Priority in its templates and it
might've gotten cop
Tollef Fog Heen wrote:
> > On kfreebsd, init would then depend on an optional package as we don't
> > support arch-specific priorities. That is (IIRC) a policy violation, but
> > do any practical problems arise from this?
>
> It would be useful to have a comment from one of the debootstrap
> maint
2014-07-17 16:31 GMT+02:00 Thorsten Glaser :
>> * https://ftp-master.debian.org/override-disparity.gz
>
> This is not shown in the PTS, though. If we could get it to show
> up there, and maybe DDPO, that could help.
Indeed, it's in yaml format, so I guess it should be easy to integrate
it in PTS
Luca Falavigna wrote:
>> Among even minbase, there are a *lot* of violations of this
>> particular rule of Policy. There is also nothing in place
>> checking them.
>
>Actually, there are two tools to check this:
> * [4]https://ftp-master.debian.org/override-disparity.gz
Ah, that's new... before
Hi!
2014-07-17 15:27 GMT+02:00 Thorsten Glaser :
>>A Priority: required package (init) isn't allowed to depend on something
>>with Priority: standard per policy.
>
> Among even minbase, there are a *lot* of violations of this
> particular rule of Policy. There is also nothing in place
> checking t
Tollef Fog Heen wrote:
>> What are the reasons behind are you going for required and not standard?
>
>A Priority: required package (init) isn't allowed to depend on something
>with Priority: standard per policy.
Among even minbase, there are a *lot* of violations of this
particular rule of Policy
]] Harald Dunkel
> On 07/16/14 23:22, Tollef Fog Heen wrote:
> > So we are proposing the following scheme:
> >
> > a/ Upload a new "init" package. This is a new, essential package that
> > will replace sysvinit as the package that ensures your system has an
> > init system. We want to build this
On 07/16/14 23:22, Tollef Fog Heen wrote:
> So we are proposing the following scheme:
>
> a/ Upload a new "init" package. This is a new, essential package that
> will replace sysvinit as the package that ensures your system has an
> init system. We want to build this binary package from a package
]] Ansgar Burchardt
> Tollef Fog Heen writes:
> > So we are proposing the following scheme:
> >
> > a/ Upload a new "init" package. This is a new, essential package that
> > will replace sysvinit as the package that ensures your system has an
> > init system. We want to build this binary package
]] Tobias Frost
> On Thu, 2014-07-17 at 03:05 +0200, Michael Biebl wrote:
> > We are planning to update the priority of systemd and systemd-sysv to
> > required and demoting sysvinit and sysvinit-core to optional.
> > I'll amend the patch for sysvinit accordingly.
>
> What are the reasons behind
On Thu, 2014-07-17 at 03:05 +0200, Michael Biebl wrote:
> Am 17.07.2014 02:31, schrieb Ben Hutchings:
> > On Wed, 2014-07-16 at 23:22 +0200, Tollef Fog Heen wrote:
> > [...]
> >> New installations
> >> =
> >> The new "init" package will ensure that systemd-sysv is installed as
> >>
Am 17.07.2014 02:31, schrieb Ben Hutchings:
> On Wed, 2014-07-16 at 23:22 +0200, Tollef Fog Heen wrote:
> [...]
>> New installations
>> =
>> The new "init" package will ensure that systemd-sysv is installed as
>> default init on Linux and by demoting the priority of sysvinit and
>>
On Wed, 2014-07-16 at 23:22 +0200, Tollef Fog Heen wrote:
[...]
> New installations
> =
> The new "init" package will ensure that systemd-sysv is installed as
> default init on Linux and by demoting the priority of sysvinit and
> sysvinit-core to optional those packages will not be
Am 16.07.2014 23:42, schrieb Ansgar Burchardt:
>> c/ Upload a new version of the init package which does the actual switch
>> and changes the order via Pre-Depends: systemd-sysv |
>> sysvinit-core. Diff[4]
>
> Why do a, and c, in two steps?
We want to have the safety measures in place before mak
Hi,
Tollef Fog Heen writes:
> So we are proposing the following scheme:
>
> a/ Upload a new "init" package. This is a new, essential package that
> will replace sysvinit as the package that ensures your system has an
> init system. We want to build this binary package from a package which
> is no
Hi all,
We're now at the point where we want to flip the default init system for
Jessie on Linux. A lot of systems have already switched over to systemd
as their init system [0] and the package received a fair amount of
testing and integration work over the last couple of months. This makes
us pr
18 matches
Mail list logo
