Re: Package not compatible with old systemd

[Jeremy Bicha]

On Wed, Sep 19, 2018 at 9:12 AM Ondrej Novy  wrote:
> but I want my package to work without init systems, for example inside 
> Docker. But if systemd is installed, I need >= version.

I think I had a much simpler situation with chrome-gnome-shell.
According to upstream, Firefox older than 56 is no longer supported.
Since chrome-gnome-shell works with several different browsers, it
doesn't depend on any particular browser (but Suggests and Enhances
them). I simply added a Breaks: firefox (<< 56), firefox-esr (<< 56)

While it's not perfectly ideal (some people want to try to hold on to
Firefox 52 ESR past its expiration date, but may have Chromium
installed), I think it's probably as good as we can get there.

Thanks,
Jeremy Bicha

Re: Package not compatible with old systemd

[Ondrej Novy]

Hi,

st 19. 9. 2018 v 10:07 odesílatel Wouter Verhelst 
napsal:

> > Conflicts is just more strict Breaks,
>
> Eh, no.
>

ehm, yes: 7.4: Conflicts ... This is a stronger restriction than Breaks

You're claiming that the systemd support of your package won't work
> correctly unless you have a particular version of systemd on your
> system. If that's the case, then you should Depend on the correct
> version of systemd. If you also support other init systems, you can add
> an alternate dependency on those other systems; or you can use
> Recommends: rather than Depends: if you don't want it to be absolute.
>

but I want my package to work without init systems, for example inside
Docker. But if systemd is installed, I need >= version.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: Package not compatible with old systemd

[Ondrej Novy]

Hi,

st 19. 9. 2018 v 13:21 odesílatel Ansgar Burchardt 
napsal:

> Policy specifically says to use Breaks in this case: "Breaks should be
> used [...] when the breaking package exposes a bug in or interacts
> badly with particular versions of the broken package." (same section as
> above)
>

according to this, I can use "Breaks" in situation, where my package is
broken with older version of other package and I can "Breaks" older version
of that not compatible (interacts badly) package.

Am I reading it correctly?

Because that means "Breaks" works both way. If A breaks B: A doesn't work
correctly with B or B doesn't work correctly with A.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: Package not compatible with old systemd

[Ansgar Burchardt]

On Wed, 2018-09-19 at 10:07 +0200, Wouter Verhelst wrote:
> On Tue, Sep 18, 2018 at 10:45:45AM +0200, Ondrej Novy wrote:
> > for example when files are overwritten. This is not case and Breaks
> > "is enough".
> 
> "Breaks" means "will cause the other package to fail". That isn't the
> case here. Additionally, Breaks isn't supported very well by some
> tools, so it's better to be avoided.

It is usally recommended to avoid Conflicts in favor of Breaks: Policy
says "Normally, Breaks should be used instead of Conflicts"[1].

  [1] 


> "Conflicts" *can* mean "shares pathnames with other package", but it
> doesn't have to; it can also mean "doesn't work well with other
> package".

Policy specifically says to use Breaks in this case: "Breaks should be
used [...] when the breaking package exposes a bug in or interacts
badly with particular versions of the broken package." (same section as
above)

> You're claiming that the systemd support of your package won't work
> correctly unless you have a particular version of systemd on your
> system. If that's the case, then you should Depend on the correct
> version of systemd. If you also support other init systems, you can
> add
> an alternate dependency on those other systems; or you can use
> Recommends: rather than Depends: if you don't want it to be absolute.

Depending on an init system is definitely wrong as it is perfectly fine
to use some service without any init, such as in Docker containers, or
under other supervisors such as runit.

Ansgar

Re: Package not compatible with old systemd

[Wouter Verhelst]

On Tue, Sep 18, 2018 at 10:45:45AM +0200, Ondrej Novy wrote:
> Hi,
> 
> út 18. 9. 2018 v 10:30 odesílatel Lars Wirzenius  napsal:
> 
> Would Conflicts work here?
> 
> 
> Conflicts is just more strict Breaks,

Eh, no.

> for example when files are overwritten. This is not case and Breaks
> "is enough".

"Breaks" means "will cause the other package to fail". That isn't the
case here. Additionally, Breaks isn't supported very well by some tools,
so it's better to be avoided.

"Conflicts" *can* mean "shares pathnames with other package", but it
doesn't have to; it can also mean "doesn't work well with other
package". Unfortunately, versioned Conflicts don't always have the
desired effect of "ensuring package X is upgraded before package Y", so
you can't rely on it in that case.

You're claiming that the systemd support of your package won't work
correctly unless you have a particular version of systemd on your
system. If that's the case, then you should Depend on the correct
version of systemd. If you also support other init systems, you can add
an alternate dependency on those other systems; or you can use
Recommends: rather than Depends: if you don't want it to be absolute.

The other options may sound better philosophically, but in practice they
turn out to be worse choices.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Package not compatible with old systemd

[Ondrej Novy]

Hi,

út 18. 9. 2018 v 12:27 odesílatel Michael Biebl  napsal:

> Fwiw, we had a similar issue in udev, see
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903224
> for the gory details.
>

thanks.


> Have you tried running your swift service with an older (say v232 from
> stable) systemd?
> Does the service fail to start or does it have a proper fallback?
>

Tried. It starts (it ignores new unit directive) and if /var/cache/swift
directory exists from past, it works fine. If it doesn't exists, some of
swift components doesn't work correctly.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: Package not compatible with old systemd

[Ondrej Novy]

Hi,

út 18. 9. 2018 v 12:18 odesílatel Michael Biebl  napsal:

>  assume you (re)start your service in postinst? In this case you need a
> running systemd >= 235 at that point.
>

yes.


> We do re-exec systemd in postinst, but a versioned Breaks or Conflicts
> does not give you the guarantee that systemd.postinst has run before
> your postinst.
>

this is not issue for me, because when I'm upgrading swift package,
/var/cache/swift directory already exists from the past (created by older
version of swift with "old" method).

Thanks.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: Package not compatible with old systemd

[Michael Biebl]

Am 18.09.18 um 12:00 schrieb Michael Biebl:
> I assume you (re)start your service in postinst? In this case you need a
> running systemd >= 235 at that point.
> We do re-exec systemd in postinst, but a versioned Breaks or Conflicts
> does not give you the guarantee that systemd.postinst has run before
> your postinst.
> 
> This is not an issue for distros which do offline updates, but for
> online updates this is problematic.
> 
> My advice would be, to only use features that systemd from stable provides.

Fwiw, we had a similar issue in udev, see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=903224
for the gory details.

Have you tried running your swift service with an older (say v232 from
stable) systemd?
Does the service fail to start or does it have a proper fallback?

Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Package not compatible with old systemd

[Michael Biebl]

Am 18.09.18 um 09:21 schrieb Ondrej Novy:
> Hi,
> 
> my package src:swift is not compatible with old systemd, because I'm
> using CacheDirectory in unit file. CacheDirectory is supported from
> systemd 235.
> 
> I think correct solution is to add to binary package this relation:
> Breaks: systemd (<< 235~)
> 
> Thomas Goirand (zigo) said it's wrong and correct solution is:
> Depends: systemd (>= 235~) | sysv-init | openrc
> 
> I don't currently depend on systemd, or any other init system.
> 
> I think my solution is correct, because Swift works with any init system
> and I want to only say "it doesn't work with older systemd". I don't
> think it's correct to list all possible init systems in Depends.
> 

I assume you (re)start your service in postinst? In this case you need a
running systemd >= 235 at that point.
We do re-exec systemd in postinst, but a versioned Breaks or Conflicts
does not give you the guarantee that systemd.postinst has run before
your postinst.

This is not an issue for distros which do offline updates, but for
online updates this is problematic.

My advice would be, to only use features that systemd from stable provides.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Package not compatible with old systemd

[Ondrej Novy]

Hi,

út 18. 9. 2018 v 10:30 odesílatel Lars Wirzenius  napsal:

> Would Conflicts work here?
>

Conflicts is just more strict Breaks, for example when files are
overwritten. This is not case and Breaks "is enough".

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: Package not compatible with old systemd

[Lars Wirzenius]

On Tue, Sep 18, 2018 at 09:21:11AM +0200, Ondrej Novy wrote:
> I think my solution is correct, because Swift works with any init system
> and I want to only say "it doesn't work with older systemd". I don't think
> it's correct to list all possible init systems in Depends.

Would Conflicts work here?

Conflicts: systemd (<< 235~)

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Package not compatible with old systemd

[Ondrej Novy]

Hi,

my package src:swift is not compatible with old systemd, because I'm
using CacheDirectory in unit file. CacheDirectory is supported from systemd
235.

I think correct solution is to add to binary package this relation:
Breaks: systemd (<< 235~)

Thomas Goirand (zigo) said it's wrong and correct solution is:
Depends: systemd (>= 235~) | sysv-init | openrc

I don't currently depend on systemd, or any other init system.

I think my solution is correct, because Swift works with any init system
and I want to only say "it doesn't work with older systemd". I don't think
it's correct to list all possible init systems in Depends.

Can you help us?

Thanks.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B