Bug#807824: RFS: arrayfire/3.2.1+dfsg1-2
On 13/12/15 21:26, Gianfranco Costamagna wrote:
Control: owner -1 !
Control: tags -1 moreinfo
Hi, the packaging looks good, however you seem to have moved files between packages, without
creating a proper upgrade path.
What do you mean ? For instance installing libarrayfire-cpu-dev still
installs the content of the old package, just via both
libarrayfire-cpu-dev **and** the new libarrayfire-dev on which it now
depends.
The reason this is needed is because each backend is an implementation
of the same headers files, so these have to be factored out in a
separate package (libarrayfire-dev).
This is an RC issue, so I'm blocking the RFS with moreinfo tag.
Please follow the wiki to fix the issue.
https://wiki.debian.org/Renaming_a_Package
https://wiki.debian.org/PackageTransition(talking about the "dev" transition, from cpu-dev to the new -dev package)
Again not sure what needs fixing. The old cpu-dev is still there and
still installs the same things.
also:
-Suggests: libarrayfire-doc
why you don't suggest it anymore?
I still do, again via the libarrayfire-dev on which each backend
(cpu-dev, opencl-dev, unified-dev) depends.
(the rest might look good, however I didn't do a full review ATM).
I might be wrong with the package transition, I didn't try a build, just looked at the debdiff.
I only did a pbuilder build + autopkgtest. For the package transition, I
believe I designed this properly.
But double-cheking does not hurt indeed.
a test build is ongoing there
http://debomatic-amd64.debian.net/distribution#unstable/arrayfire/3.2.1+dfsg1-2/buildlog
(please look at piuparts and adeguate logs=
cheers,
G.
Thanks for launching this (I have to set myself up to use deb-o-matic at
some point). I'll monitor the outcome closely.
Ghis
Reply to: