David Cournapeau wrote: > Andrew Straw wrote: > >> Fernando Perez wrote: >> >> >>> On Wed, Feb 11, 2009 at 6:17 PM, David Cournapeau <[email protected]> >>> 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 > package. 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? 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... Thanks, Andrew _______________________________________________ Numpy-discussion mailing list [email protected] http://projects.scipy.org/mailman/listinfo/numpy-discussion
