[Numpy-discussion] [SciPy-user] Numpy 1.2.1 and Scipy 0.7.0; Ubuntu packages

[David Cournapeau]

Andrew Straw wrote:
> (Warning: this email is a little over-detailed on the packaging details
> front. Believe it or not, I'm not discussing the details of Debian
> packaging for fun, but rather my questions have practical importance to
> me -- I don't want to break all my lab's scipy installations. :)

Well, the devil is in the details, specially for packaging :)

>
>
> This doesn't make sense to me. I built the .deb on an a clean, minimal
> sbuild (a chroot with only a very few basic packages installed, somewhat
> mimicing Ubuntu's PPA builder). It built from your unmodified .dsc,
> which auto-downloads the declared dependencies (and nothing else). It
> passes the tests. To be very explicit -- I didn't specify to use g77 at
> any point. (As implied by my previous statement of using your unmodified
> .dsc, I used only the debian/rules and debian/control in your package.)

Yes: your package will be almost the same as mine. It will use gfortran,
and not g77. There is nothing wrong with that per-se, but I don't think
it is a good practice in general. Here is an example which can break
things, to show that's not just red-herring:
    - install numpy from the PPA (gfortran ABI), pull gfortran as well
    - later, g77 is installed (as a dependency, whatever)
    - now, user build his own python extension with fortran extension,
or for example scipy -> uses g77, does not work anymore.

My main rationale to provide PPA is to avoid the never-ending queue of
emails about missing symbols, etc... because I am tired of it, because
it gives a bad mouth taste to users, because I would like to deal with
more interesting issues.

> To understand your statement about identical, I will operationally
> define "identical" for .debs to mean that they were built from the same
> .dsc.

I has an even larger definition of identical: same control/rules/patches
is identical for me.

> In this case, I don't see why
> an "official" package, which meets this operational definition of
> identical, wouldn't work on Hardy, as it would be built from nearly an
> identical .dsc on nearly an identical clean build environment. (Of
> course, there will never be an official package of this for Hardy, but
> that's not the point.)

Because a package has to be well integrated with the rest of the system
- I think my example above shows the problem of using a fortran compiler
which has a different ABI than the default one.

> Why is it "not really acceptable"? As long as it builds and works and
> doesn't break anything, why would Ubuntu maintainers care if it uses the
> gfortran ABI?

The problem is that it is impossible to avoid breaking anything without
using the g77 ABI on hardy. I don't understand "it is ok not to follow
the ABI as long as it does not break anything" : if there was no need to
follow an ABI to avoid breaking anything, then there would be no point
for an ABI in the first place :)

>
> Also, in practical terms, what upgrade? A) Hardy will not upgrade
> python-scipy. It's against policy for a released distribution to upgrade
> software without a security reason.

First, concerning the upgrade, I am just following the Ubuntu guide. To
quote it:

"
Ubuntu package names are suffixed by the version number of the package.
This allows Ubuntu to distinguish newer packages from older ones and so
remain up to date.

If you're creating an alternative version of a package already available
in Ubuntu's repositories, you should ensure that:

    * your package supersedes the official Ubuntu version
    * future Ubuntu versions will supersede your package.
"

As an example, I can think of backports.

>  B) Imaging for a moment that there
> would be an upgrade, why do you think it would break?

Well, if the upgraded package use the g77 ABI, and the old one the
gfortran ABI, this is quite likely to break some extensions built
against numpy/scipy I believe.

>>  In the rpm  world, you can use conditional on distribution
>> version/type int the spec file (which is the control  + changelog  +
>> rules in one file), but AFAIK, you can't do that with debian, or at
>> least have not found the relevant doc.
>>   
> I don't understand what you're saying.

One solution would be able to say in the control file: for hardy, do
this, for intrepid, do that. For example, with rpm packaging, I can do
the following:

%if 0%{?fedora_version} || 0%{?rhel_version} || 0%{?centos_version} 
BuildRequires: gcc-gfortran python python-devel lapack3-devel < 3.1
refblas3-devel
requires:       gcc-gfortran lapack3 < 3.1 refblas3
%endif

%if 0%{?suse_version}
BuildRequires:  gcc-fortran python python-devel lapack3-devel < 3.1
refblas3-devel
requires:       gcc-fortran lapack3 < 3.1 refblas3
%endif

Notice the different name for the dependency (not that this is a problem
with Ubuntu/Debian, but I would still need different packages).

>  And the point of a signed .dsc file and a clean sbuild/pbuilder is
> that any .deb that gets built will be contingent on the files in
> debian/* because that's cryptographically signed in the .dsc file. So,
> if you trust the archive master and his computer (by trusting his keys
> in your apt keyring), you trust that the .deb was built from the .dsc.
> An the .dsc is signed by the maintainer. So there's a cryptographic
> chain of trust to those control + changelog + rules files.

The problem has nothing to do with security - I am not sure I follow why
you mention signing issues.

cheers,

David