Bug#198569: [ITP]: r-noncran-design -- Regression modeling strategies
On Jun 24, Douglas Bates wrote:
> At present we have two alternatives:
>
> 1) Name the Debian source package according to the R package name, as
> Dirk suggests. I don't think this is a viable long-term strategy.
> The names, like "XML", are too vague.
Not only that, but Debian has stricter source package naming
restrictions; for example, all source and package names are required
by policy to be lowercase.
> 2) Name the expanded directory according to the Debian package name,
> build the R package under the wrong name, then rename a bunch of files
> in ./debian/tmp/usr/lib/R to the correct name of the R package before
> building the Debian package. This works - sort of. The preformatted
> help pages get messed up by this process.
A third possibility is a nasty hack (which is how all 3 of my packages
are done): wrap the upstream tar.gz inside a "fake upstream" tar.gz.
This violates Debian policy massively, makes it a real pain to upgrade
to a new upstream release using the packaging tools, and makes it
impossible to patch anything in the upstream package.
(You could slightly tweak this process by untaring the upstream
tarball. The principles remain the same.)
This makes the layout e.g.:
r-cran-foo-x.y-z/
Foo.tar.gz # Upstream tarball
debian/ # Packaging cruft
Now, imagine I have to upgrade to Foo x.y-z+1. First I need to make a
fake tarball containing the upstream Foo:
r-cran-foo-x.y-z+1/
Foo.tar.gz
Now I have to go up a directory, create r-cran-foo-x.y-z+1.tar.gz,
remove that directory, then cd into r-cran-foo-x.y-z (not z+1) and do
uupdate -v x.y-z+1 ../r-cran-foo-x.y-z+1.tar.gz. And, if it turns out
I screwed anything up, I have to start again from scratch.
If I didn't have to use this ugly hack layout, updating the packaging
for a new CRAN release of Foo would be trivial: wget the new tarball,
cd into the old unpacked Debian sources, and run uupdate -v x.y.z+1
{path to new tarball}.
> My suggested way out of this is to expand the R package installation
> mechanism to allow the package name to be other than the name of the
> directory containing the package sources. It could be overridden
> within the DESCRIPTION file or on the command line for the R CMD
> INSTALL call.
Since the DESCRIPTION file has the correct R name for the package in
it anyway, it's simply a matter of grabbing that name instead of using
the name supplied on the command line, especially since the build
process needs to unpack the tarball anyway, not to mention that it
gets the version from there too.
I realize my "simply" is not necessarily simple (i.e. will take time
to code and debug), but it seems [IMHO] more reliable than assuming
that the filename of the tarball has anything to do with what it's
supposed to be called in the R system.
Chris
--
Chris Lawrence <lawrencc@debian.org> - http://blog.lordsutch.com/
Reply to: