Bug#198569: [ITP]: r-noncran-design -- Regression modeling strategies
On Tue, Jun 24, 2003 at 09:39:41AM -0500, Chris Lawrence wrote:
> On Jun 24, Dirk Eddelbuettel wrote:
> > On Tue, Jun 24, 2003 at 02:31:53PM +0200, Andreas Rottmann wrote:
> > > Dirk Eddelbuettel <edd@debian.org> writes:
> > >
> > > > Package: wnpp
> > > > Severity: wishlist
> > > >
> > > > * Package name : r-noncran-design
> > > > Version : 1.1.6
> > > > Upstream Author : Frank Harrell <fharrell@virginia.edu>
> > > > * URL : http://hesweb1.med.virginia.edu/biostat/rms
> > > > * License : GPL
> > > > Description : Regression modeling strategies
> > > >
> > > > Design is one of two packages by Frank Harrell and requires the other, Hmisc.
> > > > Design provides the code supporting Harrell's 2002 book on 'Regression
> > > > Modeling Strategies'. I intend to stick with the convention of calling the
> > > > (Debian) source package the same as the (source) R package -- design -- but
> > > > then normalizing on r-noncran-design as done by prior packages maintained by
> > > > Chris Lawrence and myself.
> > > >
> > > I think that 'design' is, also as a source package name, way too
> > > generic. You can't in any way defer what this source package is
> > > about... The same applies (but not as much) to hmisc, IMHO. Why not
> > > name the source packages the same as the binary packages?
> >
> > a) Transparency, so 'name it the same as upstream'. CRAN packages have their
> > own little conventions and infrastructure. IMHO we gain little by adding
> > another layer of complexity.
> >
> > b) Precedence. We already have 7 or 8 R add-on packages. Several of
> > these do the same thing. In fact, mine do -- whereas Chris
> > Lawrence's don't. Doug Bates plans to release some too. Some
> > uniformity would be good.
>
> Well, to clarify, r-noncran-lindsey is a bit of a special case
> (combining half a dozen upstream packages in a bundle), and the source
Right, I had concentrated on coda and mcmcpack which are also more recent.
> package name r-cran-coda was used because there's already a coda in
> experimental. The source for r-cran-mcmcpack is simply mcmcpack; of
My bad, I thought I had checked coda and mcmcpack, maybe I didn't look to
closely at mcmcpack. Sorry!
> course, upstream is MCMCpack. My tendency (thought process) has been
> to use upstream's name unless it's horribly generic or there's an
> existing conflict.
Fully agreed.
Now, the discussion is of course following a trademark Debian pattern: it is
academic. We have no existing source 'design'. If I take the name, _and_ another
future packages desires the name, I can still rename it. Big deal.
> I really don't think the source package name matters that much.
> However, if there's a realistic chance of a conflict coming up with
> something more generic, I'd prefix with r- or r-cran- or r-noncran-;
> by that criterion, hmisc seems ok for Hmisc, but maybe r-design or
> r-noncran-design would be better for Design's source.
Well, Harrell uses 'rms' as the acronym for Regression Modeling Strategies,
his excellent Springer book. So why don't I use "rms-design"? Oh, wait, ...
Upstream is best, really. AFAIK we only really have a few conflicts,
despite three decades of 'open' Unix code. Some of these are obvious for
computers: calc vs apcalc. I still like going with design.
Dirk
--
Don't drink and derive. Alcohol and analysis don't mix.
Reply to: