On Wed, 09 Mar 2011, Piotr Ożarowski wrote:
> [Josselin Mouette, 2011-03-06]
> > You might “like” Breaks, but this:
> > Depends: python
> > Breaks: python (>= 2.8), python (<< 2.5)
> > has the same semantics as:
> > Depends: python (>= 2.5), python (<< 2.8)
>
> Yes it does; if you will not add ${python:Breaks} in debian/control,
> that's what dh_python2 will generate actually.
Having a different behaviour depending on whether a variable is listed in
a dependency or not does not look like good design to me.
> Packages with public modules do not really care about default Python
> version usually so why should they depend on python package¹?
>
> [¹] if package ships .py files, there's a dependency on python package
> due to pycompile/pyclean scripts, but if package is providing .so files
> only, there's no need for "python" in Depends
This might be true but it smells like a useless optimization at the cost
of abusing the Breaks field. First of because you use it like "IsBrokenBy"
and then because Breaks is usually used to force the upgrade of the broken
package to a non-broken version. But you're not using it that way and I'm
not sure how well APT will cope with this.
> > What is the point of doing that?
>
> Breaks will warn user if an upgrade of python can break some scripts with
> /usr/bin/python in shebang, but python-foo packages can still be usable so
> I prefer Breaks (because it's easier to override).
I really don't understand your point. If the default python is not
supported by python-foo, then it won't be coinstallable whether you're
using Depends or Breaks...
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110309221828.gb27...@rivendell.home.ouaza.com
