On Wed, Jan 28, 2015 at 02:56:17PM +0100, Michael Biebl wrote:
> 2015-01-28 1:44 GMT+01:00 Lennart Poettering :
> > I am not a fan of this stuff either. I really don't like the TOCTOU
> > behaviour I must say...
> >
> > If this is really just about ".bak", then we can add it to the list of
> > suff
2015-01-28 1:44 GMT+01:00 Lennart Poettering :
> I am not a fan of this stuff either. I really don't like the TOCTOU
> behaviour I must say...
>
> If this is really just about ".bak", then we can add it to the list of
> suffixes in hidden_files()...
Martin already committed an update [1] to at lea
On Wed, 21.01.15 19:56, Jóhann B. Guðmundsson (johan...@gmail.com) wrote:
>
> On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote:
> >>>So I expect if it gets dropped upstream, a lot of distros (and all the
> >>>major ones) wil
On Wed, 21.01.15 11:08, Martin Pitt (martin.p...@ubuntu.com) wrote:
> Hey Jóhann,
>
> "Jóhann B. Guðmundsson" [2015-01-21 9:59 +]:
> > Seems like a corner case as administrator should fix himself by not backing
> > up files in the /etc/init.d directory so arguably this broken behaviour is
>
On Wed, 21.01.15 10:46, Martin Pitt (martin.p...@ubuntu.com) wrote:
> A similar case can also happen if
> one init.d script Provides: the name of another init.d script
> (arguably this is at least questionable, but it might happen in
> practice -- e. g. /etc/init.d/mariad might very well "Provides
On 01/21/2015 08:00 PM, Michael Biebl wrote:
2015-01-21 20:56 GMT+01:00 "Jóhann B. Guðmundsson" :
On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote:
So I expect if it gets dropped upstream, a lot of distros (and all the
majo
2015-01-21 20:56 GMT+01:00 "Jóhann B. Guðmundsson" :
>
> On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote:
>>
>> On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote:
>>>
>>> >So I expect if it gets dropped upstream, a lot of distros (and all the
>>> >major ones) will have to bring
On 01/21/2015 03:43 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote:
>So I expect if it gets dropped upstream, a lot of distros (and all the
>major ones) will have to bring that back; it's IMHO better to just
>maintain it upstream by the distro
Hey Zbigniew,
Zbigniew Jędrzejewski-Szmek [2015-01-21 16:36 +0100]:
> On Wed, Jan 21, 2015 at 10:46:03AM +0100, Martin Pitt wrote:
> > Keeping track of which alias symlinks we actually want is error prone, and
> > restricting the creation of services for enabled init.d scripts would reduce
> > the
On Wed, Jan 21, 2015 at 11:08:44AM +0100, Martin Pitt wrote:
> So I expect if it gets dropped upstream, a lot of distros (and all the
> major ones) will have to bring that back; it's IMHO better to just
> maintain it upstream by the distro maintainers.
Exactly. Dropping it would be just busy work f
On Wed, Jan 21, 2015 at 10:46:03AM +0100, Martin Pitt wrote:
> Keeping track of which alias symlinks we actually want is error prone, and
> restricting the creation of services for enabled init.d scripts would reduce
> the utility of the generator (for manual starting disabled init.d scripts) as
>
Hey Jóhann,
"Jóhann B. Guðmundsson" [2015-01-21 9:59 +]:
> Seems like a corner case as administrator should fix himself by not backing
> up files in the /etc/init.d directory so arguably this broken behaviour is
> expect.
With SysV init this isn't "broken" at all. As long as you don't
actual
On 01/21/2015 09:46 AM, Martin Pitt wrote:
while working on the sysv generator, some more cases came up where the
recently introduced "Provides:" symlink handling [1] causes trouble
[2]. As soon as you have backup files like /etc/init.d/foo.bak, you'll
get a "foo.service -> foo.bak.service" link
Hello all,
while working on the sysv generator, some more cases came up where the
recently introduced "Provides:" symlink handling [1] causes trouble
[2]. As soon as you have backup files like /etc/init.d/foo.bak, you'll
get a "foo.service -> foo.bak.service" link which prevents the
creation of a
14 matches
Mail list logo
