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

[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

[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

[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

Bug#909221: ITP: python-pcl -- Python binding to the Pointcloud library (PCL)

[Jochen Sprickerhof]

Package: wnpp
Severity: wishlist
Owner: Jochen Sprickerhof 

* Package name: python-pcl
  Version : 0.3.0rc1
  Upstream Author : John Stowers 
* URL : https://strawlab.github.io/python-pcl/
* License : BSD-3-Clause
  Programming Lang: Python
  Description : Python binding to the Pointcloud library (PCL)

The following parts of the API are wrapped (all methods operate on PointXYZ)
point types:
 - I/O and integration; saving and loading PCD files
 - segmentation
 - SAC
 - smoothing
 - filtering
 - registration (ICP, GICP, ICP_NL)

I want to package it as part of the Python module team

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