On Thu, 17.05.12 16:00, Colin Guthrie ([email protected]) wrote:
> >> Or do you think it's not even worth it (medium
> >> term goal is probably to disable support for non-native units at compile
> >> time anyway I guess...)
> >
> > I think we will keep that for a long time. We plan though, to
]] Michael Biebl
> We've seen this quite often on Debian, too, due to sysv init scripts
> doing "interesting" stuff, like being both started in rcS.d and rc2.d.
This should have been fixed in e51db373c242b7541794affb2b5e411bcce26d0f.
More logic to handle non-sensical cases would be good. We sho
2012/5/17 Kay Sievers :
> On Thu, May 17, 2012 at 4:02 PM, Colin Guthrie wrote:
>> I know this has been discussed a lot but it's still showing up for me on
>> occasion, especially with 3rd party non-LSB init scripts.
>>
>> My suggestion would be to prioritise the jobs that we delete... can we
>> t
'Twas brillig, and Kay Sievers at 17/05/12 15:18 did gyre and gimble:
> On Thu, May 17, 2012 at 4:02 PM, Colin Guthrie wrote:
>> I know this has been discussed a lot but it's still showing up for me on
>> occasion, especially with 3rd party non-LSB init scripts.
>>
>> My suggestion would be to pri
On Thu, May 17, 2012 at 4:02 PM, Colin Guthrie wrote:
> I know this has been discussed a lot but it's still showing up for me on
> occasion, especially with 3rd party non-LSB init scripts.
>
> My suggestion would be to prioritise the jobs that we delete... can we
> tell that a job relates to a uni
I know this has been discussed a lot but it's still showing up for me on
occasion, especially with 3rd party non-LSB init scripts.
My suggestion would be to prioritise the jobs that we delete... can we
tell that a job relates to a unit? And if so can we tell if a unit is
sysv, lsb or native? If so
