[Numpy-discussion] [SciPy-user] Numpy 1.2.1 and Scipy 0.7.0; Ubuntu packages
Thu Feb 12 04:53:17 CST 2009
David Cournapeau wrote:
> Andrew Straw wrote:
>> Fernando Perez wrote:
>>> On Wed, Feb 11, 2009 at 6:17 PM, David Cournapeau <firstname.lastname@example.org> wrote:
>>>> Unfortunately, it does require some work, because hardy uses g77
>>>> instead of gfortran, so the source package has to be different (once
>>>> hardy is done, all the one below would be easy, though). I am not sure
>>>> how to do that with PPA (the doc is not great).
>>> OK, thanks for the info. This is already very useful.
>> What exactly is the expected problem and how would I verify that I'm not
>> getting hit by it?
> I want to follow as closely as possible the official debian/ubuntu
> packages. Ideally, any package produced on the PPA superseded by an
> official package (from 1.2.1-1~ppaN to 1.2.1-1) should be identical to
> the superseding package. Hardy default fortran ABI is g77, not gfortran,
> so I have to use g77 for hardy - and the ppa package, limited to
> intrepid, use gfortran (since intrepid ABI is gfortran's).
(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. :)
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.)
To understand your statement about identical, I will operationally
define "identical" for .debs to mean that they were built from the same
.dsc. Of course, in the case you describe above, it can't be _exactly_
the same .dsc because the version numbers in debian/changelog must
change and consequently so must the checksums and GPG signature in the
.dsc file, and presumably a different person will sign it. Also, there
will be timestamp differences and such for two .debs built from the
exact same .dsc, but we can ignore those. 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.)
> In your case, you built a package which uses gfortran ABI on Hardy - it
> works, but is not really acceptable for an official package - and thus,
> when an upgrade from ppa to official happens, you won't get the same
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
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. B) Imaging for a moment that there
would be an upgrade, why do you think it would break?
> 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. My understanding is that at the
beginning of each distribution (Hardy, Intrepid, Lenny), the maintainers
decide on a C++ (and I guess Fortran, but I'm not sure) ABI and fix the
toolchain to build this ABI. From then on, everything is built with this
ABI. 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.
I'm still not sure if I'm not getting your worry, though...
More information about the Numpy-discussion